Messages in this thread | | | Date | Fri, 06 Jan 2012 01:33:01 -0500 | From | KOSAKI Motohiro <> | Subject | Re: [PATCH] mm: do not drain pagevecs for mlock |
| |
(1/6/12 1:30 AM), Tao Ma wrote: > On 01/06/2012 02:18 PM, KOSAKI Motohiro wrote: >> 2012/1/6 Tao Ma<tm@tao.ma>: >>> Hi Kosaki, >>> On 12/30/2011 06:07 PM, KOSAKI Motohiro wrote: >>>>>> Because your test program is too artificial. 20sec/100000times = >>>>>> 200usec. And your >>>>>> program repeat mlock and munlock the exact same address. so, yes, if >>>>>> lru_add_drain_all() is removed, it become near no-op. but it's >>>>>> worthless comparision. >>>>>> none of any practical program does such strange mlock usage. >>>>> yes, I should say it is artificial. But mlock did cause the problem in >>>>> our product system and perf shows that the mlock uses the system time >>>>> much more than others. That's the reason we created this program to test >>>>> whether mlock really sucks. And we compared the result with >>>>> rhel5(2.6.18) which runs much much faster. >>>>> >>>>> And from the commit log you described, we can remove lru_add_drain_all >>>>> safely here, so why add it? At least removing it makes mlock much faster >>>>> compared to the vanilla kernel. >>>> >>>> If we remove it, we lose to a test way of mlock. "Memlocked" field of >>>> /proc/meminfo >>>> show inaccurate number very easily. So, if 200usec is no avoidable, >>>> I'll ack you. >>>> But I'm not convinced yet. >>> Do you find something new for this? >> >> No. >> >> Or more exactly, 200usec is my calculation mistake. your program call mlock >> 3 times per each iteration. so, correct cost is 66usec. > yes, so mlock can do 15000/s, it is even slower than the whole i/o time > for some not very fast ssd disk and I don't think it is endurable. I > guess we should remove it, right? Or you have another other suggestion > that I can try for it?
read whole thread.
| |