[lkml]   [1996]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectPossible improvement to pipe throughput

David Miller was angling for a faster SPARC memcpy to improve pipe
throughput speed. While thinking about that I though of what might
be a general improvement. It all depends on how fast page table
tweaking is on various platforms. For a pipe_read of the whole
buffered page, instead of just using memcpy_to_fs, one could just
tweak the page table to swap the virtual-to-physical mappings for
the two pages. That way, instead of incurring the cost of actually
copying the data, you incur the cost of a page table tweak. Since
the kernel doesn't need the data again, it doesn't matter that the
new PIPEBASE points to junk (what used to be the current task's
page). You may need force a page-in first (in case the user's page
is paged out) but in general the page would be in memory already.

If page table tweaks/flushes/whatever are slow then it's not worth
it of course. Does anyone have any ballpark figures? The
optimisation would only happen when it was a write of exactly
PAGE_SIZE bytes to a page-aligned destination. For programs which
want high throughput through pipes that might be fairly common though.


Malcolm Beattie <>
Oxford University Computing Services
"Widget. It's got a widget. A lovely widget. A widget it has got." --Jack Dee

 \ /
  Last update: 2005-03-22 13:37    [W:0.085 / U:4.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site