On Thu, Aug 20, 2020 at 2:51 AM Alex Shi <alex.shi@xxxxxxxxxxxxxxxxx> wrote: > > > > 在 2020/8/19 下午10:57, Alexander Duyck 写道: > >>> lruvec = relock_page_lruvec_irqsave(page, lruvec, &flags); > >> the lock bounce is better with the patch, would you like to do further > >> like using add_lruvecs to reduce bounce more? > >> > >> Thanks > >> Alex > > I'm not sure how much doing something like that would add. In my case > > I had a very specific issue that this is addressing which is the fact > > that every compound page was taking the LRU lock and zone lock > > separately. With this patch that is reduced to one LRU lock per 15 > > pages and then the zone lock per page. By adding or sorting pages by > > lruvec I am not sure there will be much benefit as I am not certain > > how often we will end up with pages being interleaved between multiple > > lruvecs. In addition as I am limiting the quantity to a pagevec which > > limits the pages to 15 I am not sure there will be much benefit to be > > seen for sorting the pages beforehand. > > > > the relock will unlock and get another lock again, the cost in that, the 2nd > lock need to wait for fairness for concurrency lruvec locking. > If we can do sort before, we should remove the fairness waiting here. Of course, > perf result depends on scenarios. Agreed. The question is in how many scenarios are you going to have pages interleaved between more than one lruvec? I suspect in most cases you should only have one lruvec for all the pages being processed in a single pagevec.
