VM υποσύστημα και διαχωρισμός 1-3:3-4 GB

[Giorgos Keramidas]

On 2005-04-25 22:12, Vasilis Vasaitis <v.vasaitis at sms.ed.ac.uk> wrote:
>On Mon, Apr 25, 2005 at 12:10:10PM +0300, Giorgos Keramidas wrote:
>> Ένα μεγάλο μέρος της δουλειάς που κάνει ο πυρήνας κάθε φορά που
>> εκτελείται ένα system call είναι η αντιγραφή δεδομένων από userlevel
>> σε kernel space.  Για να υλοποιηθεί αυτό υπαχουν δύο τρόποι:
>>
>> α) Να είναι mapped όλο το address space του πυρήνα στο πάνω μέρος του
>>    virtual address space κάθε διεργασίας.
>> β) Να γίνεται "overlay" όλο το 4 GB address space ενός process με
>>    αυτό του πυρήνα κάθε φορά που γίνεται ένα context switch από
>>    userspace σε kernel mode.
>
> Να αναφέρω πάντως και τον αντίλογο... Στο Linux, η δεύτερη περίπτωση
> που περιγράφεις υλοποιείται με το περίφημο 4G/4G patch του Ingo Molnar
> [0, 1, 2], το οποίο πάντως δεν έχει ενσωματωθεί στον πυρήνα, και
> μάλλον ούτε και πρόκειται. Αυτό όντως μπορεί να έχει κόστος μέχρι και
> 30% στα syscall, αλλά υπάρχουν περιπτώσεις που είναι πραγματικά
> χρήσιμο: Αν έχεις μια εφαρμογή υπολογιστικής φύσεως κατά βάση, που
> περνάει τον περισσότερο χρόνο της κάνοντας επεξεργασία σε user space,
> και η οποία *χρειάζεται* τα 4GB, τότε είναι κάτι πραγματικά χρήσιμο.
> Αυτό δεν είναι υποθετικό σενάριο· το συγκεκριμένο patch
> χρησιμοποιείται αρκετά ακριβώς για τέτοιες εφαρμογές, με κόστος ακόμα
> και της τάξης του 0,1% μόλις σε αρκετές περιπτώσεις.

Δεν ξέρω πως υλοποιείται στο Linux το preemption στον πυρήνα, αλλά έχω
την εντύπωση ότι κάτι τέτοιο δε θα ήταν ιδιαίτερα βιώσιμο σε FreeBSD
(εκτός από πολύ συγκεκριμένες, ρυθμισμένες "με το χέρι" καταστάσεις).
Κι αυτό επειδή ακόμα και τα interrupt handlers των devices έχουν ένα
τουλάχιστον kernel thread με δικό του context attached το καθένα.
Κάτι που σημαίνει πως ακόμα και CPU bound διεργασίες θα διακόπτονται
πολλές φορές το δευτερόλεπτο, όταν π.χ. ο πυρήνας πρέπει να εξυπηρετήσει
ένα interrupt της κάρτας δικτύου/οθόνης/κλπ, όταν ξυπνάει ο scheduler
έτσι κι αλλιώς, κλπ.

Πολύ ενδιαφέρον το link πάντως :-)