Re: [RFC] madvise(MADV_TRUNCATE)

[Andrea Arcangeli <andrea@suse.de>]

On Thu, Oct 27, 2005 at 01:50:58PM -0700, Andrew Morton wrote:
> This is what I'm asking about.  What's the requirement?  What's the
> application?  What's the workload?  What's the testcase?  All that old
> stuff.  This should have been the very, very first thing which Badari
> presented to us.

I mentioned the reason we need that feature at the end of the last email.

> If we do it this way then we should do it for other filesystems.  And then

Why do you think so? Even O_DIRECT and the acl were not supported by all
the fs immediately, what's wrong with that? This is normal procedure as
far as I can tell. If -ENOSYS is returned, it means the app should
fallback to some other way to do the truncate by hand (depending on the
app, bzero could work or some other app can be ok with doing nothing at
all if -ENOSYS is returned).

> we should do it for files which _aren't_ mmapped.  And then we should do it
> on a finer-than-PAGE_SIZE granularity.

I agree with this. I also suggested doing all of it, not just the mmap
interface. However the only thing they care about is the mmap interface,
and this is why this is coming first. Also note, my MADV_TRUNCATE is by
coincidence needed by IBM too, the testcase I was trying to improve was
not an IBM workload, I learnt about the IBM effort only a few days ago.
But others happen to need it for the very same reason (no, not Oracle,
but Oracle would benefit from it too of course).

> IOW: we're unlikely to implement MADV_TRUNCATE for anything other than
> tmpfs, in which case MADV_TRUNCATE will remain a tmpfs specific hack, no?

In 2.6 yes. But in the future it's an API we can extend to work on more
fs with well defined semantics.

What's the benefit in having MADV_DISCARD that works on tmpfs, and then
some day in the future to add a MADV_TRUNCATE that works on other fs too?

The retval of MADV_TRUNCATE will still be an error in both cases for
older kernels. So we may go for the more generic API in the first place
IMHO.

The less MADV_MESS there is the better and the more explicit the name is
the better too.

> Or to swap it out.

Ok, the whole point is to release the swap. This stuff is already in
completely swap for ages, nobody touched it for ages, but it's bad for
performance and for swap fragmentation if after a peak of load 16G
remains always in swap when infact the app could release all the
swap after the load went down (if only it could use MADV_TRUNCATE).
 
At some point during the lifetime of the appliaction thousand of clients
connects, each one allocats from tmpfs, then when the load goes down we
want to free the swap that contains no useful info anymore. Perhaps such
a peak load will never happen again in the lifetime of the application,
and we want to have swap available for other usages. munmap isn't
enough, that's tmpfs backed storage, only truncate can release the swap.

> I think we need to restart this discussion.  Can we please have a

Sure no problem.

> *detailed* description of the problem?

Hope the above clarifies some more bits.

--
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>