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

2018-04-17 Thread Vlastimil Babka
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

2018-04-17 Thread Vlastimil Babka
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] multipathd will not set the iscsi session tmo after iscsi sesstion recovery

2018-04-17 Thread jianchao.wang
Would anyone please provide some suggestion ? Thanks in advance Jianchao On 04/12/2018 04:46 PM, jianchao.wang wrote: > Hi Dear all > > Our customer complained that the iscsi session tmo parameters doesn't match > with > the multipath config. > > When the iscsi session fails and do the

Re: [dm-devel] [PATCH RESEND 2/2] lvm2: 69-dm-lvm-metad.rules: set systemd vars on "change"

2018-04-17 Thread Peter Rajnoha
On 04/16/2018 08:53 PM, Martin Wilck wrote: > The current logic that avoids setting SYSTEMD_ALIAS and SYSTEMD_WANTS > on "change" events is flawed in the default "systemd background job" > configuration. For systemd, it's important that device properties don't > change spuriously. > > If an "add"

Re: [dm-devel] [PATCH RESEND 1/2] lvm2: 69-dm-lvm-metad.rules: explicit pvscan rule

2018-04-17 Thread Peter Rajnoha
On 04/16/2018 08:53 PM, Martin Wilck wrote: > Make the distinction between the cases with and without systemd > background jobs explicit in 69-dm-lvm-metad.rules rather than > substituting the rule from the Makefile. At this stage, > this improves only readibility, at the cost of one GOTO

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

2018-04-17 Thread Christopher Lameter
On Mon, 16 Apr 2018, Vlastimil Babka wrote: > >> Its not a senseless increase. The more objects you fit into a slab page > >> the higher the performance of the allocator. > > It's not universally without a cost. It might increase internal > fragmentation of the slabs, if you end up with lots of

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

2018-04-17 Thread Christopher Lameter
On Mon, 16 Apr 2018, Mikulas Patocka wrote: > dm-bufio deals gracefully with allocation failure, because it preallocates > some buffers with vmalloc, but other subsystems may not deal with it and > they cound return ENOMEM randomly or misbehave in other ways. So, the > "SLAB_MINIMIZE_WASTE" flag

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

2018-04-17 Thread Christopher Lameter
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 to use dm-bufio for deduplication index and > there are

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

2018-04-17 Thread Christopher Lameter
On Tue, 17 Apr 2018, Vlastimil Babka wrote: > On 04/17/2018 04:45 PM, Christopher Lameter wrote: > > But then higher order allocs are generally seen as problematic. > > I think in this case they are better than wasting/fragmenting 384kB for > 640kB object. Well typically we have suggested that

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

2018-04-17 Thread Christopher Lameter
On Mon, 16 Apr 2018, Mikulas Patocka wrote: > If you boot with slub_max_order=10, the kmalloc-8192 cache has 64 pages. > So yes, it increases the order of all slab caches (although not up to > 4MB). Hmmm... Ok. There is another setting slub_min_objects that controls how many objects to fit into

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

2018-04-17 Thread Mikulas Patocka
On Tue, 17 Apr 2018, Christopher Lameter wrote: > On Tue, 17 Apr 2018, Vlastimil Babka wrote: > > > On 04/17/2018 04:45 PM, Christopher Lameter wrote: > > > > But then higher order allocs are generally seen as problematic. > > > > I think in this case they are better than wasting/fragmenting

Re: [dm-devel] [patch 2/2] dm-delay: add third flush class

2018-04-17 Thread Mikulas Patocka
On Tue, 17 Apr 2018, Mike Snitzer wrote: > On Mon, Apr 16 2018 at 6:33pm -0400, > Mikulas Patocka wrote: > > > This patch adds a new class for dm-delay that delays flush requests. > > Previously, flushes were delayed as writes, but it caused problems if the > > user

Re: [dm-devel] multipathd will not set the iscsi session tmo after iscsi sesstion recovery

2018-04-17 Thread Benjamin Marzinski
On Tue, Apr 17, 2018 at 10:11:48AM +0800, jianchao.wang wrote: > Would anyone please provide some suggestion ? > > Thanks in advance > Jianchao > > On 04/12/2018 04:46 PM, jianchao.wang wrote: > > Hi Dear all > > > > Our customer complained that the iscsi session tmo parameters doesn't match >

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

2018-04-17 Thread Mikulas Patocka
On Tue, 17 Apr 2018, 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

Re: [dm-devel] [patch 2/2] dm-delay: add third flush class

2018-04-17 Thread Mike Snitzer
On Mon, Apr 16 2018 at 6:33pm -0400, Mikulas Patocka wrote: > This patch adds a new class for dm-delay that delays flush requests. > Previously, flushes were delayed as writes, but it caused problems if the > user needed to create a device with one or few slow sectors for

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

2018-04-17 Thread Mikulas Patocka
On Tue, 17 Apr 2018, Christopher Lameter wrote: > On Mon, 16 Apr 2018, Mikulas Patocka wrote: > > > dm-bufio deals gracefully with allocation failure, because it preallocates > > some buffers with vmalloc, but other subsystems may not deal with it and > > they cound return ENOMEM randomly or

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

2018-04-17 Thread Mikulas Patocka
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_MINIMIZE_WASTE for slab and slub. This > >> flag causes allocation of larger slab caches in order to

[dm-devel] [PATCH] dm-integrity: use kvfree

2018-04-17 Thread Mikulas Patocka
Use kvfree instead of kfree because the array is allocated with kvmalloc. Signed-off-by: Mikulas Patocka Cc: sta...@vger.kernel.org # v4.12+ --- drivers/md/dm-integrity.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index:

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

2018-04-17 Thread Christopher Lameter
On Tue, 17 Apr 2018, Mikulas Patocka wrote: > > > The slub subsystem does actual fallback to low-order when the allocation > > > fails (it allows different order for each slab in the same cache), but > > > slab doesn't fallback and you get NULL if higher-order allocation fails. > > > So,