Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1424332 > unrolled thread

RE: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page arrival

Started by"Odzioba, Lukasz" <lukasz.odzioba@intel.com>
First post2016-06-16 20:10 +0200
Last post2016-06-16 22:10 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  RE: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page  arrival "Odzioba, Lukasz" <lukasz.odzioba@intel.com> - 2016-06-16 20:10 +0200
    Re: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page  arrival Michal Hocko <mhocko@kernel.org> - 2016-06-16 20:20 +0200
      RE: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page  arrival "Odzioba, Lukasz" <lukasz.odzioba@intel.com> - 2016-06-16 22:10 +0200

#1424332 — RE: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page arrival

From"Odzioba, Lukasz" <lukasz.odzioba@intel.com>
Date2016-06-16 20:10 +0200
SubjectRE: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page arrival
Message-ID<rKJTP-3eJ-17@gated-at.bofh.it>
On Thru 09-06-16 02:22 PM Michal Hocko wrote:
> I agree it would be better to do the same for others as well. Even if
> this is not an immediate problem for those.

I am not able to find clear reasons why we shouldn't do it for the rest.
Ok so what do we do now? I'll send v2 with proposed changes.
Then do we still want  to have stats on those pvecs?
In my opinion it's not worth it now.

Thanks,
Lukas

[toc] | [next] | [standalone]


#1424338

FromMichal Hocko <mhocko@kernel.org>
Date2016-06-16 20:20 +0200
Message-ID<rKK3w-3hY-17@gated-at.bofh.it>
In reply to#1424332
On Thu 16-06-16 18:08:57, Odzioba, Lukasz wrote:
> On Thru 09-06-16 02:22 PM Michal Hocko wrote:
> > I agree it would be better to do the same for others as well. Even if
> > this is not an immediate problem for those.
> 
> I am not able to find clear reasons why we shouldn't do it for the rest.
> Ok so what do we do now? I'll send v2 with proposed changes.
> Then do we still want  to have stats on those pvecs?
> In my opinion it's not worth it now.

I think the fix has a higher priority - we also want to backport it to
stable trees IMO. We can discuss the stats and how to present them
later.
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]


#1424369

From"Odzioba, Lukasz" <lukasz.odzioba@intel.com>
Date2016-06-16 22:10 +0200
Message-ID<rKLLX-4lm-3@gated-at.bofh.it>
In reply to#1424338
On Thu 16-06-16 08:19 PM, Michal Hocko wrote:
>
> On Thu 16-06-16 18:08:57, Odzioba, Lukasz wrote:
> I am not able to find clear reasons why we shouldn't do it for the rest.
> Ok so what do we do now? I'll send v2 with proposed changes.
> Then do we still want  to have stats on those pvecs?
> In my opinion it's not worth it now.
>
> I think the fix has a higher priority - we also want to backport it to
> stable trees IMO. We can discuss the stats and how to present them
> later.

Will send the patch tomorrow. In the meantime I was able get similar
problem on lru_deactivate by using MADV_FREE:

LRU_add              588 =    18704kB
LRU_rotate             0 =        0kB
LRU_deactivate       165 =   309304kB
LRU_deact_file         0 =        0kB
LRU_activate           0 =        0kB

Thanks,
Lukas

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web