Re: [PATCH V5 6/6] proc: show MADV_FREE pages info in smaps

Hi Andrew,

On Tue, Mar 07, 2017 at 02:43:38PM -0800, Andrew Morton wrote:

On Tue, 7 Mar 2017 11:05:45 +0100 Michal Hocko [off-list ref] wrote:

quoted

On Fri 03-03-17 16:10:27, Andrew Morton wrote:

quoted

On Thu, 2 Mar 2017 17:30:54 +0100 Michal Hocko [off-list ref] wrote:

quoted

quoted

It's not that I think you're wrong: it *is* an implementation detail.
But we take a bit of incoherency from batching all over the place, so
it's a little odd to take a stand over this particular instance of it
- whether demanding that it'd be fixed, or be documented, which would
only suggest to users that this is special when it really isn't etc.

I am not aware of other counter printed in smaps that would suffer from
the same problem, but I haven't checked too deeply so I might be wrong. 

Anyway it seems that I am alone in my position so I will not insist.
If we have any bug report then we can still fix it.

A single lru_add_drain_all() right at the top level (in smaps_show()?)
won't kill us

I do not think we want to put lru_add_drain_all cost to a random
process reading /proc/<pid>/smaps.

Why not?  It's that process which is calling for the work to be done.

quoted

If anything the one which does the
madvise should be doing this.

But it would be silly to do extra work in madvise() if nobody will be
reading smaps for the next two months.

How much work is it anyway?  What would be the relative impact upon a
smaps read?

I agree only if the draining guarantees all of mapped pages in the range
could be marked to lazyfree. However, it's not true because there are a
few of logics to skip the page marking in madvise_free_pte_range.

So, my conclusion is drainning helps a bit but not gaurantees.
In such case, IMHO, let's not do the effort to make better.

Thanks.

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