[lkml]   [1999]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread

Who's idea was it start the work to make the granularity of the page
cache larger?

From what I can tell:
(a) It can save on finding multiple pages
(b) allows larger internal fragmentation of memory.
(c) Isn't needed if you just need a large chunk of the page
cache at a time. (It isn't hard to tie 2 or more pages to
together if you need to).

This is something I'm stumbling over porting patches for large
files in the page cache from 2.2.5 to to 2.3.3.

I guess if it's worth it I would like to talk with whoever is
responsible so we can coordinate our efforts.

Otherwise I would like this code dropped.

Non-page cache aligned mappings sound great until you
(a) squeeze the extra bits out of the vm_offset and make it an index
into the page cache, and
(b) realize you need more bits to say how far you are into a page.


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 13:51    [W:0.074 / U:0.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site