On Fri, 27 Apr 2018, Christopher Lameter wrote:
> On Thu, 26 Apr 2018, Mikulas Patocka wrote:
>
> > > Hmmm... order 4 for these caches may cause some concern. These should stay
> > > under costly order I think. Otherwise allocations are no longer
> > > guaranteed.
> >
> > You said that slub
On Fri, 27 Apr 2018, Christopher Lameter wrote:
> On Thu, 26 Apr 2018, Mikulas Patocka wrote:
>
> > > Hmmm... order 4 for these caches may cause some concern. These should stay
> > > under costly order I think. Otherwise allocations are no longer
> > > guaranteed.
> >
> > You said that slub
On Thu, 26 Apr 2018, Mikulas Patocka wrote:
> > Hmmm... order 4 for these caches may cause some concern. These should stay
> > under costly order I think. Otherwise allocations are no longer
> > guaranteed.
>
> You said that slub has fallback to smaller order allocations.
Yes it does...
> The
On Thu, 26 Apr 2018, Mikulas Patocka wrote:
> > Hmmm... order 4 for these caches may cause some concern. These should stay
> > under costly order I think. Otherwise allocations are no longer
> > guaranteed.
>
> You said that slub has fallback to smaller order allocations.
Yes it does...
> The
On Thu, 26 Apr 2018, Christopher Lameter wrote:
> On Wed, 25 Apr 2018, Mikulas Patocka wrote:
>
> > Do you want this? It deletes slab_order and replaces it with the
> > "minimize_waste" logic directly.
>
> Well yes that looks better. Now we need to make it easy to read and less
> complicated.
On Thu, 26 Apr 2018, Christopher Lameter wrote:
> On Wed, 25 Apr 2018, Mikulas Patocka wrote:
>
> > Do you want this? It deletes slab_order and replaces it with the
> > "minimize_waste" logic directly.
>
> Well yes that looks better. Now we need to make it easy to read and less
> complicated.
On Wed, 25 Apr 2018, Mikulas Patocka wrote:
> Do you want this? It deletes slab_order and replaces it with the
> "minimize_waste" logic directly.
Well yes that looks better. Now we need to make it easy to read and less
complicated. Maybe try to keep as much as possible of the old code
and also
On Wed, 25 Apr 2018, Mikulas Patocka wrote:
> Do you want this? It deletes slab_order and replaces it with the
> "minimize_waste" logic directly.
Well yes that looks better. Now we need to make it easy to read and less
complicated. Maybe try to keep as much as possible of the old code
and also
On Wed, 25 Apr 2018, Mikulas Patocka wrote:
> >
> > Could yo move that logic into slab_order()? It does something awfully
> > similar.
>
> But slab_order (and its caller) limits the order to "max_order" and we
> want more.
>
> Perhaps slab_order should be dropped and calculate_order totally
>
On Wed, 25 Apr 2018, Mikulas Patocka wrote:
> >
> > Could yo move that logic into slab_order()? It does something awfully
> > similar.
>
> But slab_order (and its caller) limits the order to "max_order" and we
> want more.
>
> Perhaps slab_order should be dropped and calculate_order totally
>
On Wed, 25 Apr 2018, Mikulas Patocka wrote:
>
>
> On Wed, 18 Apr 2018, Christopher Lameter wrote:
>
> > On Tue, 17 Apr 2018, Mikulas Patocka wrote:
> >
> > > I can make a slub-only patch with no extra flag (on a freshly booted
> > > system it increases only the order of caches "TCPv6" and
On Wed, 25 Apr 2018, Mikulas Patocka wrote:
>
>
> On Wed, 18 Apr 2018, Christopher Lameter wrote:
>
> > On Tue, 17 Apr 2018, Mikulas Patocka wrote:
> >
> > > I can make a slub-only patch with no extra flag (on a freshly booted
> > > system it increases only the order of caches "TCPv6" and
On Wed, 18 Apr 2018, Christopher Lameter wrote:
> On Tue, 17 Apr 2018, Mikulas Patocka wrote:
>
> > I can make a slub-only patch with no extra flag (on a freshly booted
> > system it increases only the order of caches "TCPv6" and "sighand_cache"
> > by one - so it should not have unexpected
On Wed, 18 Apr 2018, Christopher Lameter wrote:
> On Tue, 17 Apr 2018, Mikulas Patocka wrote:
>
> > I can make a slub-only patch with no extra flag (on a freshly booted
> > system it increases only the order of caches "TCPv6" and "sighand_cache"
> > by one - so it should not have unexpected
On Tue, 17 Apr 2018, Mikulas Patocka wrote:
> I can make a slub-only patch with no extra flag (on a freshly booted
> system it increases only the order of caches "TCPv6" and "sighand_cache"
> by one - so it should not have unexpected effects):
>
> Doing a generic solution for slab would be more
On Tue, 17 Apr 2018, Mikulas Patocka wrote:
> I can make a slub-only patch with no extra flag (on a freshly booted
> system it increases only the order of caches "TCPv6" and "sighand_cache"
> by one - so it should not have unexpected effects):
>
> Doing a generic solution for slab would be more
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_MINIMIZE_WASTE for slab and slub. This
flag
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_MINIMIZE_WASTE for slab and slub. This
flag
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
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
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
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
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
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
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
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
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
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
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
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
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 existing installations with non-power-of-two block sizes
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 existing installations with non-power-of-two block sizes
32 matches
Mail list logo
