[lkml]   [2000]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PATCH: killing read_ahead[]

On Thu, 26 Oct 2000, Linus Torvalds wrote:

> The alternative is to have an entirely different approach, where the page
> cache itself only knows about the maximum page (in which case your current
> "last_page" calculation is right on), and then anybody who needs to know
> about partial pages needs to get THAT information from the inode.
> I'd almost prefer the alternative approach. Especially as right now the
> only real problem we're fighting is to make sure we never return an
> invalid page - the sub-page offset really doesn't matter for those things,
> and everybody who cares about the sub-page-information already obviously
> has it.

s/everybody/almost &/
There are only two places where we really care. And one of them can be
trivially shot.
* O_APPEND handling. Well, duh - we can take the main loop
of generic_file_write() into a separate function (do_generic_file_write())
and be done with that - grab the semaphore, possibly adjust the ->f_pos,
pass the actor to do_generic_file_write(), be happy.
* do_generic_file_read() should know how much to copy from the
last page. We could push that into the actor. Or we could mirror that
data in struct address_space.

But yes, 99% of cases care only about the index of last page. So
I really don't think that size>>PAGE_CACHE_SHIFT makes sense from VM point
of view.

OK, I have the "push to actor" variant and I'll send it once it
will get some testing. Changing it to "mirror both" is not a problem, anyway.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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