Re: [dm-devel] [RFC PATCH 1/2] mempool: do not consume memory reserves from the reclaim path

On 07/22/2016 08:37 AM, Michal Hocko wrote: On Thu 21-07-16 16:53:09, Michal Hocko wrote: From d64815758c212643cc1750774e2751721685059a Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Thu, 21 Jul 2016 16:40:59 +0200 Subject: [PATCH] Revert "mm, mempool: only set

Re: [dm-devel] [PATCH] slab: introduce the flag SLAB_MINIMIZE_WASTE

On 03/21/2018 07:36 PM, Mikulas Patocka wrote: > > > On Wed, 21 Mar 2018, Christopher Lameter wrote: > >> On Wed, 21 Mar 2018, Mikulas Patocka wrote: >> You should not be using the slab allocators for these. Allocate higher order pages or numbers of consecutive smaller pagess from the

Re: [dm-devel] slab: introduce the flag SLAB_MINIMIZE_WASTE

On 04/16/2018 09:36 PM, Mikulas Patocka wrote: > > > On Mon, 16 Apr 2018, Christopher Lameter wrote: > >> On Mon, 16 Apr 2018, Mikulas Patocka wrote: >> Or an increase in slab_max_order >>> >>> But that will increase it for all slabs (often senselessly - i.e. >>> kmalloc-4096 would

Re: [dm-devel] slab: introduce the flag SLAB_MINIMIZE_WASTE

On 04/16/2018 04:37 PM, Mikulas Patocka wrote: >>> Can you or Mikulas briefly summarize how the dependency is avoided, and >>> whether if (something like) SLAB_MINIMIZE_WASTE were implemented, the >>> dm-bufio code would happily switch to it, or not? >> >> git log

Re: [dm-devel] [PATCH RESEND] slab: introduce the flag SLAB_MINIMIZE_WASTE

On 04/17/2018 04:45 PM, Christopher Lameter wrote: > On Mon, 16 Apr 2018, Mikulas Patocka wrote: > >> This patch introduces a flag SLAB_MINIMIZE_WASTE for slab and slub. This >> flag causes allocation of larger slab caches in order to minimize wasted >> space. >> >> This is needed because we want

Re: [dm-devel] [PATCH RESEND] slab: introduce the flag SLAB_MINIMIZE_WASTE

On 04/17/2018 07:26 PM, Mikulas Patocka wrote: > > > On Tue, 17 Apr 2018, Vlastimil Babka wrote: > >> On 04/17/2018 04:45 PM, Christopher Lameter wrote: >>> On Mon, 16 Apr 2018, Mikulas Patocka wrote: >>> >>>> This patch introduces a flag SLAB_

Re: [dm-devel] slab: introduce the flag SLAB_MINIMIZE_WASTE

On 04/13/2018 05:10 PM, Mike Snitzer wrote: > On Fri, Apr 13 2018 at 5:22am -0400, > Vlastimil Babka <vba...@suse.cz> wrote: >> >> Would this perhaps be a good LSF/MM discussion topic? Mikulas, are you >> attending, or anyone else that can vouch for your usecas

Re: [dm-devel] [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM

On 04/19/2018 06:12 PM, Mikulas Patocka wrote: > From: Mikulas Patocka > Subject: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM > > The kvmalloc function tries to use kmalloc and falls back to vmalloc if > kmalloc fails. > > Unfortunatelly, some kernel code has

Re: [dm-devel] [PATCH] SLUB: Do not fallback to mininum order if __GFP_NORETRY is set

On 04/20/2018 04:53 PM, Christopher Lameter wrote: > On Thu, 19 Apr 2018, Michal Hocko wrote: > >> Overriding __GFP_NORETRY is just a bad idea. It will make the semantic >> of the flag just more confusing. Note there are users who use >> __GFP_NORETRY as a way to suppress heavy memory pressure

[dm-devel] [PATCH for 6.5 regression] PM: hibernate: fix resume_store() return value when hibernation not available

be written, as that's what was done before the commit. Fixes: cc89c63e2fe3 ("PM: hibernate: move finding the resume device out of software_resume") Signed-off-by: Vlastimil Babka Reviewed-by: Christoph Hellwig Acked-by: Greg Kroah-Hartman --- Resend with review/ack tags added and not buried

Re: [dm-devel] [PATCH 04/24] PM: hibernate: move finding the resume device out of software_resume

have the sysfs locking nest inside it. > > Signed-off-by: Christoph Hellwig > Acked-by: Rafael J. Wysocki This caused a regression for me in 6.5-rc1+, fix below. 8< >From 95a310ae6cfae9b3cab61e54a1bce488c3ab93a1 Mon Sep 17 00:00:00 2001 From: Vlastimil Babka Date: Wed, 2 A

Re: [dm-devel] [PATCH 29/29] mm: shrinker: move shrinker-related code into a separate file

On 6/22/23 10:53, Qi Zheng wrote: > The mm/vmscan.c file is too large, so separate the shrinker-related > code from it into a separate file. No functional changes. > > Signed-off-by: Qi Zheng Maybe do this move as patch 01 so the further changes are done in the new file already? -- dm-devel

Re: [dm-devel] [PATCH 24/29] mm: vmscan: make global slab shrink lockless

On 6/22/23 10:53, Qi Zheng wrote: > The shrinker_rwsem is a global read-write lock in > shrinkers subsystem, which protects most operations > such as slab shrink, registration and unregistration > of shrinkers, etc. This can easily cause problems in > the following cases. > > 1) When the memory

Re: [dm-devel] [PATCH 01/29] mm: shrinker: add shrinker::private_data field

On 6/22/23 10:53, Qi Zheng wrote: > To prepare for the dynamic allocation of shrinker instances > embedded in other structures, add a private_data field to > struct shrinker, so that we can use shrinker::private_data > to record and get the original embedded structure. > > Signed-off-by: Qi Zheng