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

Dave Kleikamp
2007-08-30T02:15:13Z

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