Re: I/O and memory managment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Joseph,

Thank you for your quick answer. I am afraid I was not sufficiently clear about the details in my scenario. So let me re-phrase the situation:

A and B are threads (i.e. they share their VM). Thread A initiates a disk-read and sleeps. Thread B calls fork(), creating a process C. I didn't mention process C in my previous
mail, since it is not relevant to the susequent scenario. With respect to this scenario the only relevant effect of B's call to fork() is that all pages within B's address space
are now marked copy-on-write (and the same holds for the pages within A's address space, since A and B share their address spaces).


> > (2) How is I/O synchronized with the copy-on-write mechanism? Imagine the following scenario:
> >
> > (i) Two threads A and B share their virtual address space (i.e. the CLONE_VM flag was set when A called clone() to create B).
> >
> > (ii) Thread A starts reading data from a hard disk into a buffer BUF which lies within virtual page VP_1 (which at that moment corresponds to the physical page PP_1). In
> > order to service the read request, the physical page PP_1 is locked (?) and DMA is set up, to transfer data from the harddisk into the correct location within physical page
> > PP_1.
> >
> > (iii) Thread A sleeps until termination of it's read request.
>
> You really mean "process" here, because threads share VM (so
> no copy-on-write, etc.)

No, A and B are threads and they *do* share their VM, by assumption. copy-on-write results from B's call to fork() and will result in separating A and B's address space from the
address space of the newly created process C.

>
>
> > (iv) Meanwhile thread B calls fork(), which results in write protection of the virtual page VP_1 (in order to enforce a copy on write at a subsequent write access).
>
> If Process B tries to write VP_1, it will get a page fault (either
> due to the page not yet being mapped, or due to the copy-on-write
> state), find the page in the page cache, and get it its own copy
> mapped into its VM. Unless we -know- a page is shareable, the writing
> process always gets its own copy, and any mappings to the old
> page are left unchanged.
>
> > (v) Thread B writes to the virtual page VP_1 (outside the buffer BUF). This results in a page fault, and subsequently in a copy on write (COW) of the virtual page VP_1. As
> > a consequence of the COW, the content of PP_1 is copied into a new physical page PP_2 and virtual page VP_1 is associated to PP_2 (by modifying the respective page table
> > entry for thread A and B).
>
> Nope. B gets its own copy, A uses the existing one. So A's
> read() completes normally.

But A and B share their address space ...


regards
Martin


--
Supercomputing System AG          email: maletinsky@scs.ch
Martin Maletinsky                 phone: +41 (0)1 445 16 05
Technoparkstrasse 1               fax:   +41 (0)1 445 16 10
CH-8005 Zurich


-
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
IRC Channel:   irc.openprojects.net / #kernelnewbies
Web Page:      http://www.kernelnewbies.org/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux