lkml.org 
[lkml]   [2006]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] VM: I have a dream...
    On Mon, Jan 23, 2006 at 01:40:46PM -0500, Valdis.Kletnieks@vt.edu wrote:
    > A process does a "read(foo, &buffer, 65536);". buffer is declared as 16
    > contiguous 4K pages, none of which are currently in memory. How many pages do
    > you have to read in, and at what point do you issue the I/O? (hint - work this
    > problem for a device that's likely to return 64K of data, and again for a
    > device that has a high chance of only returning 2K of data.....)

    Actually, that is something that the vm could optimize out of the picture
    entirely -- it is a question of whether it is worth the added complexity
    to handle such a case. copy_to_user already takes a slow path when it hits
    the page fault (we do a lookup on the exception handler already) and could
    test if an entire page is being overwritten, and if so proceed to destroy
    the old mapping and use a fresh page from ram.

    That said, for the swap case, it probably happens so rarely that the extra
    code isn't worth it. glibc is already using mmap() in place of read() for
    quite a few apps, so I'm not sure how much low hanging fruit there is left.
    If someone has an app that's read() heavy, it is probably easier to convert
    it to mmap() -- the exception being pipes and sockets which can't. We need
    numbers. =-)

    -ben
    --
    "Ladies and gentlemen, I'm sorry to interrupt, but the police are here
    and they've asked us to stop the party." Don't Email: <dont@kvack.org>.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-01-23 20:32    [W:3.142 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site