Re: [RFC:PATCH 00/07] VM File Tails

[Dave Kleikamp <shaggy@linux.vnet.ibm.com>]

On Thu, 2007-08-30 at 01:38 +0200, Jorn Engel wrote:
> On Wed, 29 August 2007 21:45:42 +0000, Dave Kleikamp wrote:
> > On Wed, 2007-08-29 at 23:31 +0200, Jorn Engel wrote:
> > > On Wed, 29 August 2007 16:53:25 -0400, Dave Kleikamp wrote:
> > > >
> > > > - benchmark!
> > > 
> > > I'd love to know how much difference this makes.  Basically four
> > > numbers:
> > > - number of address spaces
> > > - bytes allocated for file tails
> > > - number of pages allocated for non-tail storage
> > > - number of pages allocated for tail storage
> > 
> > The last one may be tricky, since I'm allocating the tails using
> > kmalloc.  The data will be interspersed with other kmalloc'ed data.  We
> > could keep track of the bytes, and the number of tails, but we wouldn't
> > know exactly how the tail bytes correspond to the number of pages needed
> > to store them.
> 
> Sorry, I should have been more precise.  Under some circumstances like
> mmap() you have to allocate a page and copy the tail to that page.  My
> last point was about the number of such pages, not the number of pages
> buried in slab caches.
> 
> Iiuc your current implementation would keep the kmalloc()-allocated tail
> in the address space and _additionally_ have a full page for the same
> data.  So the patches aimed to save memory may actually waste memory and
> depending on circumstances may waste more than they save.  Or did I
> misinterpret something?

Once the data is packed into the tail, the page is freed.  Later if the
page is needed, a new page is allocated and the tail is unpacked into
it.  Then the tail is freed (via kfree).
-- 
David Kleikamp
IBM Linux Technology Center

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>