On Fri, 2016-12-02 at 16:37 +0100, Jesper Dangaard Brouer wrote:
> On Thu, 01 Dec 2016 23:17:48 +0100
> Paolo Abeni wrote:
>
> > On Thu, 2016-12-01 at 18:34 +0100, Jesper Dangaard Brouer wrote:
> > > (Cc. netdev, we might have an issue with Paolo's UDP accounting and
> > >
On Fri, 2016-12-02 at 16:37 +0100, Jesper Dangaard Brouer wrote:
> On Thu, 01 Dec 2016 23:17:48 +0100
> Paolo Abeni wrote:
>
> > On Thu, 2016-12-01 at 18:34 +0100, Jesper Dangaard Brouer wrote:
> > > (Cc. netdev, we might have an issue with Paolo's UDP accounting and
> > > small socket queues)
>
On Thu, 01 Dec 2016 23:17:48 +0100
Paolo Abeni wrote:
> On Thu, 2016-12-01 at 18:34 +0100, Jesper Dangaard Brouer wrote:
> > (Cc. netdev, we might have an issue with Paolo's UDP accounting and
> > small socket queues)
> >
> > On Wed, 30 Nov 2016 16:35:20 +
> > Mel Gorman
On Thu, 01 Dec 2016 23:17:48 +0100
Paolo Abeni wrote:
> On Thu, 2016-12-01 at 18:34 +0100, Jesper Dangaard Brouer wrote:
> > (Cc. netdev, we might have an issue with Paolo's UDP accounting and
> > small socket queues)
> >
> > On Wed, 30 Nov 2016 16:35:20 +
> > Mel Gorman wrote:
> >
> >
On Thu, 2016-12-01 at 18:34 +0100, Jesper Dangaard Brouer wrote:
> (Cc. netdev, we might have an issue with Paolo's UDP accounting and
> small socket queues)
>
> On Wed, 30 Nov 2016 16:35:20 +
> Mel Gorman wrote:
>
> > > I don't quite get why you are setting the
On Thu, 2016-12-01 at 18:34 +0100, Jesper Dangaard Brouer wrote:
> (Cc. netdev, we might have an issue with Paolo's UDP accounting and
> small socket queues)
>
> On Wed, 30 Nov 2016 16:35:20 +
> Mel Gorman wrote:
>
> > > I don't quite get why you are setting the socket recv size
> > > (with
(Cc. netdev, we might have an issue with Paolo's UDP accounting and
small socket queues)
On Wed, 30 Nov 2016 16:35:20 +
Mel Gorman wrote:
> > I don't quite get why you are setting the socket recv size
> > (with -- -s and -S) to such a small number, size + 256.
>
(Cc. netdev, we might have an issue with Paolo's UDP accounting and
small socket queues)
On Wed, 30 Nov 2016 16:35:20 +
Mel Gorman wrote:
> > I don't quite get why you are setting the socket recv size
> > (with -- -s and -S) to such a small number, size + 256.
> >
>
> Maybe I missed
On Wed, Nov 30, 2016 at 04:06:12PM +0100, Jesper Dangaard Brouer wrote:
> > > [...]
> > > > This is the result from netperf running UDP_STREAM on localhost. It was
> > > > selected on the basis that it is slab-intensive and has been the subject
> > > > of previous SLAB vs SLUB comparisons with
On Wed, Nov 30, 2016 at 04:06:12PM +0100, Jesper Dangaard Brouer wrote:
> > > [...]
> > > > This is the result from netperf running UDP_STREAM on localhost. It was
> > > > selected on the basis that it is slab-intensive and has been the subject
> > > > of previous SLAB vs SLUB comparisons with
On Wed, 30 Nov 2016 14:06:15 +
Mel Gorman wrote:
> On Wed, Nov 30, 2016 at 01:40:34PM +0100, Jesper Dangaard Brouer wrote:
> >
> > On Sun, 27 Nov 2016 13:19:54 + Mel Gorman
> > wrote:
> >
> > [...]
> > > SLUB has been the
On Wed, 30 Nov 2016 14:06:15 +
Mel Gorman wrote:
> On Wed, Nov 30, 2016 at 01:40:34PM +0100, Jesper Dangaard Brouer wrote:
> >
> > On Sun, 27 Nov 2016 13:19:54 + Mel Gorman
> > wrote:
> >
> > [...]
> > > SLUB has been the default small kernel object allocator for quite some
> > >
On Wed 30-11-16 14:16:13, Mel Gorman wrote:
> On Wed, Nov 30, 2016 at 02:05:50PM +0100, Michal Hocko wrote:
[...]
> > But... Unless I am missing something this effectively means that we do
> > not exercise high order atomic reserves. Shouldn't we fallback to
> > the locked
On Wed 30-11-16 14:16:13, Mel Gorman wrote:
> On Wed, Nov 30, 2016 at 02:05:50PM +0100, Michal Hocko wrote:
[...]
> > But... Unless I am missing something this effectively means that we do
> > not exercise high order atomic reserves. Shouldn't we fallback to
> > the locked
On Wed, Nov 30, 2016 at 02:05:50PM +0100, Michal Hocko wrote:
> On Sun 27-11-16 13:19:54, Mel Gorman wrote:
> [...]
> > @@ -2588,18 +2594,22 @@ struct page *buffered_rmqueue(struct zone
> > *preferred_zone,
> > struct page *page;
> > bool cold = ((gfp_flags & __GFP_COLD) != 0);
> >
> >
On Wed, Nov 30, 2016 at 02:05:50PM +0100, Michal Hocko wrote:
> On Sun 27-11-16 13:19:54, Mel Gorman wrote:
> [...]
> > @@ -2588,18 +2594,22 @@ struct page *buffered_rmqueue(struct zone
> > *preferred_zone,
> > struct page *page;
> > bool cold = ((gfp_flags & __GFP_COLD) != 0);
> >
> >
On Wed, Nov 30, 2016 at 01:40:34PM +0100, Jesper Dangaard Brouer wrote:
>
> On Sun, 27 Nov 2016 13:19:54 + Mel Gorman
> wrote:
>
> [...]
> > SLUB has been the default small kernel object allocator for quite some time
> > but it is not universally used due to
On Wed, Nov 30, 2016 at 01:40:34PM +0100, Jesper Dangaard Brouer wrote:
>
> On Sun, 27 Nov 2016 13:19:54 + Mel Gorman
> wrote:
>
> [...]
> > SLUB has been the default small kernel object allocator for quite some time
> > but it is not universally used due to performance concerns and a
On Sun 27-11-16 13:19:54, Mel Gorman wrote:
[...]
> @@ -2588,18 +2594,22 @@ struct page *buffered_rmqueue(struct zone
> *preferred_zone,
> struct page *page;
> bool cold = ((gfp_flags & __GFP_COLD) != 0);
>
> - if (likely(order == 0)) {
> + if (likely(order <=
On Sun 27-11-16 13:19:54, Mel Gorman wrote:
[...]
> @@ -2588,18 +2594,22 @@ struct page *buffered_rmqueue(struct zone
> *preferred_zone,
> struct page *page;
> bool cold = ((gfp_flags & __GFP_COLD) != 0);
>
> - if (likely(order == 0)) {
> + if (likely(order <=
On Sun, 27 Nov 2016 13:19:54 + Mel Gorman
wrote:
[...]
> SLUB has been the default small kernel object allocator for quite some time
> but it is not universally used due to performance concerns and a reliance
> on high-order pages. The high-order concerns has
On Sun, 27 Nov 2016 13:19:54 + Mel Gorman
wrote:
[...]
> SLUB has been the default small kernel object allocator for quite some time
> but it is not universally used due to performance concerns and a reliance
> on high-order pages. The high-order concerns has two major components --
>
On Mon, Nov 28, 2016 at 12:00:41PM +0100, Vlastimil Babka wrote:
> > 1-socket 6 year old machine
> > 4.9.0-rc5 4.9.0-rc5
> > vanilla hopcpu-v3
> > Hmeansend-64 87.47 ( 0.00%) 127.14 (
On Mon, Nov 28, 2016 at 12:00:41PM +0100, Vlastimil Babka wrote:
> > 1-socket 6 year old machine
> > 4.9.0-rc5 4.9.0-rc5
> > vanilla hopcpu-v3
> > Hmeansend-64 87.47 ( 0.00%) 127.14 (
On 11/28/2016 07:54 PM, Christoph Lameter wrote:
> On Mon, 28 Nov 2016, Mel Gorman wrote:
>
>> If you have a series aimed at parts of the fragmentation problem or how
>> subsystems can avoid tracking 4K pages in some important cases then by
>> all means post them.
>
> I designed SLUB with defrag
On 11/28/2016 07:54 PM, Christoph Lameter wrote:
> On Mon, 28 Nov 2016, Mel Gorman wrote:
>
>> If you have a series aimed at parts of the fragmentation problem or how
>> subsystems can avoid tracking 4K pages in some important cases then by
>> all means post them.
>
> I designed SLUB with defrag
On Sun, Nov 27, 2016 at 01:19:54PM +, Mel Gorman wrote:
> While it is recognised that this is a mixed bag of results, the patch
> helps a lot more workloads than it hurts and intuitively, avoiding the
> zone->lock in some cases is a good thing.
>
> Signed-off-by: Mel Gorman
On Sun, Nov 27, 2016 at 01:19:54PM +, Mel Gorman wrote:
> While it is recognised that this is a mixed bag of results, the patch
> helps a lot more workloads than it hurts and intuitively, avoiding the
> zone->lock in some cases is a good thing.
>
> Signed-off-by: Mel Gorman
This seems like
On Mon, 28 Nov 2016, Mel Gorman wrote:
> If you have a series aimed at parts of the fragmentation problem or how
> subsystems can avoid tracking 4K pages in some important cases then by
> all means post them.
I designed SLUB with defrag methods in mind. We could warm up some old
patchsets that
On Mon, 28 Nov 2016, Mel Gorman wrote:
> If you have a series aimed at parts of the fragmentation problem or how
> subsystems can avoid tracking 4K pages in some important cases then by
> all means post them.
I designed SLUB with defrag methods in mind. We could warm up some old
patchsets that
On Mon, Nov 28, 2016 at 10:38:58AM -0600, Christoph Lameter wrote:
> > > that only insiders know how to tune and an overall fragile solution.
> > While I agree with all of this, it's also a problem independent of this
> > patch.
>
> It is related. The fundamental issue with fragmentation remain
On Mon, Nov 28, 2016 at 10:38:58AM -0600, Christoph Lameter wrote:
> > > that only insiders know how to tune and an overall fragile solution.
> > While I agree with all of this, it's also a problem independent of this
> > patch.
>
> It is related. The fundamental issue with fragmentation remain
On Mon, 28 Nov 2016, Mel Gorman wrote:
> Yes, that's a problem for SLUB with or without this patch. It's always
> been the case that SLUB relying on high-order pages for performance is
> problematic.
This is a general issue in the kernel. Performance often requires larger
contiguous ranges of
On Mon, 28 Nov 2016, Mel Gorman wrote:
> Yes, that's a problem for SLUB with or without this patch. It's always
> been the case that SLUB relying on high-order pages for performance is
> problematic.
This is a general issue in the kernel. Performance often requires larger
contiguous ranges of
On Mon, Nov 28, 2016 at 09:39:19AM -0600, Christoph Lameter wrote:
> On Sun, 27 Nov 2016, Mel Gorman wrote:
>
> >
> > SLUB has been the default small kernel object allocator for quite some time
> > but it is not universally used due to performance concerns and a reliance
> > on high-order pages.
On Mon, Nov 28, 2016 at 09:39:19AM -0600, Christoph Lameter wrote:
> On Sun, 27 Nov 2016, Mel Gorman wrote:
>
> >
> > SLUB has been the default small kernel object allocator for quite some time
> > but it is not universally used due to performance concerns and a reliance
> > on high-order pages.
On Sun, 27 Nov 2016, Mel Gorman wrote:
>
> SLUB has been the default small kernel object allocator for quite some time
> but it is not universally used due to performance concerns and a reliance
> on high-order pages. The high-order concerns has two major components --
> high-order pages are not
On Sun, 27 Nov 2016, Mel Gorman wrote:
>
> SLUB has been the default small kernel object allocator for quite some time
> but it is not universally used due to performance concerns and a reliance
> on high-order pages. The high-order concerns has two major components --
> high-order pages are not
On Mon, Nov 28, 2016 at 12:00:41PM +0100, Vlastimil Babka wrote:
> On 11/27/2016 02:19 PM, Mel Gorman wrote:
> >
> > 2-socket modern machine
> > 4.9.0-rc5 4.9.0-rc5
> > vanilla hopcpu-v3
> > Hmeansend-64
On Mon, Nov 28, 2016 at 12:00:41PM +0100, Vlastimil Babka wrote:
> On 11/27/2016 02:19 PM, Mel Gorman wrote:
> >
> > 2-socket modern machine
> > 4.9.0-rc5 4.9.0-rc5
> > vanilla hopcpu-v3
> > Hmeansend-64
On 11/27/2016 02:19 PM, Mel Gorman wrote:
2-socket modern machine
4.9.0-rc5 4.9.0-rc5
vanilla hopcpu-v3
Hmeansend-64 178.38 ( 0.00%) 256.74 ( 43.93%)
Hmeansend-128351.49 (
On 11/27/2016 02:19 PM, Mel Gorman wrote:
2-socket modern machine
4.9.0-rc5 4.9.0-rc5
vanilla hopcpu-v3
Hmeansend-64 178.38 ( 0.00%) 256.74 ( 43.93%)
Hmeansend-128351.49 (
Changelog since v2
o Correct initialisation to avoid -Woverflow warning
SLUB has been the default small kernel object allocator for quite some time
but it is not universally used due to performance concerns and a reliance
on high-order pages. The high-order concerns has two major components --
Changelog since v2
o Correct initialisation to avoid -Woverflow warning
SLUB has been the default small kernel object allocator for quite some time
but it is not universally used due to performance concerns and a reliance
on high-order pages. The high-order concerns has two major components --
44 matches
Mail list logo