Re: [PATCH 1/2] SHM_UNLOCK: fix long unpreemptible section
From: Hugh Dickins <hughd@google.com>
Date: 2012-01-18 23:27:09
Also in:
lkml, stable
On Wed, 18 Jan 2012, Andrew Morton wrote:
On Sat, 14 Jan 2012 16:18:43 -0800 (PST) Hugh Dickins [off-list ref] wrote:quoted
scan_mapping_unevictable_pages() is used to make SysV SHM_LOCKed pages evictable again once the shared memory is unlocked. It does this with pagevec_lookup()s across the whole object (which might occupy most of memory), and takes 300ms to unlock 7GB here. A cond_resched() every PAGEVEC_SIZE pages would be good.... Is -stable backporting really warranted? AFAICT the only thing we're fixing here is a long latency glitch during a rare operation on large machines. Usually it will be on only one CPU, too.
True: I'm not sure if it amounts to -stable material or not. I see you've taken out its Cc: stable line: that's fine by me, but...
"[PATCH 2/2] SHM_UNLOCK: fix Unevictable pages stranded after swap" does loko like -stable material, so omitting 1/1 will probably screw things up :(
Sort of, but they both(?) needed respinning for -stable anyway. Even against 3.2, there's some little change in vmscan.c that generates a reject. Greg has now closed down 3.1.N (which would have been tiresome to port to, because it was still supporting a second caller of check_move), and by your argument above it's not worth porting 1/2 back to 2.6.32. So I think 2/2 can just go into 3.2.N, dragging 1/2 along in its slipstream (if you can have a slipstream in front of you). I ordered them that way because 1/2 fixes an old, and 2/2 a recent, bug.
quoted
Resend in the hope that it can get into 3.3.That we can do ;)
Thank you!
quoted
+#else +void scan_mapping_unevictable_pages(struct address_space *mapping) +{ +} +#endif /* CONFIG_SHMEM */Inlining the CONFIG_SHMEM=n stub would have been mroe efficient.
True, though in 2/2 it morphs into shmem_unlock_mapping() over in shmem.c, and we seem to have the convention that TINY's !SHMEM stubs live as non-inline functions there - probably no good reason for that, just reflects their historical origins in tiny-shmem.c. A grand saving to make some other time ;) Hugh -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>