LKML Archive on
help / color / mirror / Atom feed
From: David Hildenbrand <>
To: Yang Shi <>,,,,,
Subject: Re: [PATCH 1/2] mm: hwpoison: don't drop slab caches for offlining non-LRU page
Date: Mon, 16 Aug 2021 21:15:03 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 16.08.21 20:09, Yang Shi wrote:
> In the current implementation of soft offline, if non-LRU page is met,
> all the slab caches will be dropped to free the page then offline.  But
> if the page is not slab page all the effort is wasted in vain.  Even
> though it is a slab page, it is not guaranteed the page could be freed
> at all.

... but there is a chance it could be and the current behavior is 
actually helpful in some setups.


> The lockup made the machine is quite unusable.  And it also made the
> most workingset gone, the reclaimabled slab caches were reduced from 12G
> to 300MB, the page caches were decreased from 17G to 4G.
> But the most disappointing thing is all the effort doesn't make the page
> offline, it just returns:
> soft_offline: 0x1469f2: unknown non LRU page type 5ffff0000000000 ()

In your example, yes. I had a look at the introducing commit: 
facb6011f399 ("HWPOISON: Add soft page offline support")

     When the page is not free or LRU we try to free pages
     from slab and other caches. The slab freeing is currently
     quite dumb and does not try to focus on the specific slab
     cache which might own the page. This could be potentially
     improved later.

I wonder, if instead of removing it altogether, we could actually 
improve it as envisioned.

To be precise, for alloc_contig_range() it would also make sense to be 
able to shrink only in a specific physical memory range; this here seems 
to be a similar thing. (actually, alloc_contig_range(), actual memory 
offlining and hw poisoning/soft-offlining have a lot in common)

Unfortunately, the last time I took a brief look at teaching shrinkers 
to be range-aware, it turned out to be a lot of work ... so maybe this 
is really a long term goal to be mitigated in the meantime by disabling 
it, if it turns out to be more of a problem than actually help.


David / dhildenb

  parent reply	other threads:[~2021-08-16 19:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-16 18:09 Yang Shi
2021-08-16 18:09 ` [PATCH 2/2] doc: hwpoison: correct the support for hugepage Yang Shi
2021-08-18  6:36   ` HORIGUCHI NAOYA(堀口 直也)
2021-08-16 19:02 ` [PATCH 1/2] mm: hwpoison: don't drop slab caches for offlining non-LRU page David Hildenbrand
2021-08-16 19:04   ` David Hildenbrand
2021-08-16 19:15 ` David Hildenbrand [this message]
2021-08-16 19:37   ` Yang Shi
2021-08-16 19:40     ` David Hildenbrand
2021-08-16 19:37 ` Matthew Wilcox
2021-08-16 20:24   ` Yang Shi
2021-08-18  5:02     ` HORIGUCHI NAOYA(堀口 直也)
2021-08-18 17:45       ` Yang Shi
2021-08-18  6:30 ` Naoya Horiguchi
2021-08-18  7:24   ` David Hildenbrand
2021-08-18  7:53     ` HORIGUCHI NAOYA(堀口 直也)
2021-08-18  7:55       ` David Hildenbrand
2021-08-18 17:04         ` Yang Shi
2021-08-18 17:02   ` Yang Shi
2021-08-18 18:01   ` Yang Shi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 1/2] mm: hwpoison: don'\''t drop slab caches for offlining non-LRU page' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).