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


Groups > linux.kernel > #1418151

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

From "Odzioba, Lukasz" <lukasz.odzioba@intel.com>
Newsgroups linux.kernel
Subject RE: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page arrival
Date 2016-06-09 10:10 +0200
Message-ID <rI3cl-3Hx-3@gated-at.bofh.it> (permalink)
References <rHMOe-1mm-23@gated-at.bofh.it> <rHNhg-1Mf-47@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed 08-07-16 17:04:00, Michal Hocko wrote: 
> I do not see how a SIGTERM would make any difference. But see below.

This is how we encounter this problem initially, by hitting ctr-c while
running parallel  memory intensive workload, which ended up
not calling munmap on allocated memory.

> Is this really true? Both munmap and exit_mmap do the same
> lru_add_drain() which flushes only the local CPU cache so munmap
> shouldn't make any difference.

Damn, I forgot to escape # in pragma parallel, it should be
void main(){
#pragma parallel
{
(...)

And then yes, exit_mmap will flush just the local CPU cache, but not the
rest. This would be another way of fixing the problem, but I concluded
that it would hurt performance on short running processes like scripts
if we do it synchronously, and we will be racing with next processes if 
we do it asynchronously, not tested it though.

> I believe this deserves a more explanation. What do you think about the
> following.
> "
> The primary point of the LRU add cache is to save the zone lru_lock
> contention with a hope that more pages will belong to the same zone
> and so their addition can be batched. The huge page is already a
> form of batched addition (it will add 512 worth of memory in one go)
> so skipping the batching seems like a safer option when compared to a
> potential excess in the caching which can be quite large and much
> harder to fix because lru_add_drain_all is way to expensive and
> it is not really clear what would be a good moment to call it.
>"
>
> Does this sound better?

Far better, thanks.

Lukas

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page arrival Lukasz Odzioba <lukasz.odzioba@intel.com> - 2016-06-08 16:40 +0200
  Re: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page  arrival Michal Hocko <mhocko@kernel.org> - 2016-06-08 17:10 +0200
    RE: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page  arrival "Odzioba, Lukasz" <lukasz.odzioba@intel.com> - 2016-06-09 10:10 +0200
  Re: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page  arrival Dave Hansen <dave.hansen@intel.com> - 2016-06-08 17:40 +0200
    Re: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page  arrival Michal Hocko <mhocko@kernel.org> - 2016-06-08 18:10 +0200
      Re: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page  arrival Dave Hansen <dave.hansen@intel.com> - 2016-06-08 18:40 +0200
        Re: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page  arrival Michal Hocko <mhocko@kernel.org> - 2016-06-09 14:30 +0200
    RE: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page  arrival "Odzioba, Lukasz" <lukasz.odzioba@intel.com> - 2016-06-09 11:00 +0200
      Re: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page  arrival Dave Hansen <dave.hansen@intel.com> - 2016-06-09 17:50 +0200

csiph-web