Hugh Dickins wrote:
On Wed, 22 Feb 2012, Konstantin Khlebnikov wrote:
Hugh Dickins wrote:
I'll have to come back to think about your locking later too;
or maybe that's exactly where I need to look, when investigating
the mm_inline.h:41 BUG.
pages_count[] updates looks correct.
This really may be bug in locking, and this VM_BUG_ON catch it before
list-debug.
I've still not got into looking at it yet.
You're right to mention DEBUG_LIST: I have that on some of the machines,
and I would expect that to be the first to catch a mislocking issue.
In the past my problems with that BUG (well, the spur to introduce it)
came from hugepages.
My patchset hasn't your mem_cgroup_reset_uncharged_to_root protection,
or something to replace it. So, there exist race between cgroup remove and
isolated uncharged page put-back, but it shouldn't corrupt lru lists.
There something different.
But at first sight, I have to say I'm very suspicious: I've never found
PageLRU a good enough test for whether we need such a lock, because of
races with those pages on percpu lruvec about to be put on the lru.
But maybe once I look closer, I'll find that's handled by your changes
away from lruvec; though I'd have thought the same issue exists,
independent of whether the pending pages are in vector or list.
Are you talking about my per-cpu page-lists for lru-adding?
Yes.
This is just an unnecessary patch, I don't know why I include it into v2 set.
It does not protect anything.
Okay.
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>