On Tue, Apr 12, 2016 at 08:16:49AM +0200, Jesper Dangaard Brouer wrote:
>
> On Mon, 11 Apr 2016 15:21:26 -0700
> Alexei Starovoitov wrote:
>
> > On Mon, Apr 11, 2016 at 11:41:57PM +0200, Jesper Dangaard Brouer wrote:
> > >
> > > On Sun, 10 Apr 2016 21:45:47 +0300 Sagi Grimberg wrote:
> > >
On Mon, Apr 11, 2016 at 11:28 PM, Jesper Dangaard Brouer
wrote:
>
> On Mon, 11 Apr 2016 15:02:51 -0700 Alexander Duyck
> wrote:
>
>> Have you taken a look at possibly trying to optimize the DMA pool API
>> to work with pages? It sounds like it is supposed to do something
>> similar to what you
On Mon, 11 Apr 2016 15:02:51 -0700 Alexander Duyck
wrote:
> Have you taken a look at possibly trying to optimize the DMA pool API
> to work with pages? It sounds like it is supposed to do something
> similar to what you are wanting to do.
Yes, I have looked at the mm/dmapool.c API. AFAIK this
On Mon, 11 Apr 2016 15:21:26 -0700
Alexei Starovoitov wrote:
> On Mon, Apr 11, 2016 at 11:41:57PM +0200, Jesper Dangaard Brouer wrote:
> >
> > On Sun, 10 Apr 2016 21:45:47 +0300 Sagi Grimberg wrote:
> >
[...]
> > >
> > > If we go down this road how about also attaching some driver opaques
On Mon, Apr 11, 2016 at 11:41:57PM +0200, Jesper Dangaard Brouer wrote:
>
> On Sun, 10 Apr 2016 21:45:47 +0300 Sagi Grimberg wrote:
>
> > >> This is also very interesting for storage targets, which face the same
> > >> issue. SCST has a mode where it caches some fully constructed SGLs,
> > >> w
On Mon, Apr 11, 2016 at 2:41 PM, Jesper Dangaard Brouer
wrote:
>
> On Sun, 10 Apr 2016 21:45:47 +0300 Sagi Grimberg wrote:
>
>> >> This is also very interesting for storage targets, which face the same
>> >> issue. SCST has a mode where it caches some fully constructed SGLs,
>> >> which is proba
On Sun, 10 Apr 2016 21:45:47 +0300 Sagi Grimberg wrote:
> >> This is also very interesting for storage targets, which face the same
> >> issue. SCST has a mode where it caches some fully constructed SGLs,
> >> which is probably very similar to what NICs want to do.
> >
> > I think a cached al
On Mon, 2016-04-11 at 22:23 +0200, Jesper Dangaard Brouer wrote:
> If we have a page-pool recycle facility, then we could use the trick,
> right? (As we know that get_page_unless_zero() cannot happen for pages
> in the pool).
Well, if you disable everything that possibly use
get_page_unless_zero(
On Mon, 2016-04-11 at 21:47 +0200, Jesper Dangaard Brouer wrote:
> On Mon, 11 Apr 2016 09:53:54 -0700
> Eric Dumazet wrote:
>
> > On Mon, 2016-04-11 at 18:19 +0200, Jesper Dangaard Brouer wrote:
> >
> > > Drivers also do tricks where they fallback to smaller order pages. E.g.
> > > lookup functi
On Sat, 09 Apr 2016 05:34:38 -0700 Eric Dumazet wrote:
> On Sat, 2016-04-09 at 11:11 +0200, Jesper Dangaard Brouer wrote:
>
> > Above code is okay. But do you think we also can get away with the same
> > trick we do with the SKB refcnf? Where we avoid an atomic operation if
> > refcnt==1.
> >
On Mon, 11 Apr 2016 09:53:54 -0700
Eric Dumazet wrote:
> On Mon, 2016-04-11 at 18:19 +0200, Jesper Dangaard Brouer wrote:
>
> > Drivers also do tricks where they fallback to smaller order pages. E.g.
> > lookup function mlx4_alloc_pages(). I've tried to simulate that
> > function here:
> > http
On Mon, 11 Apr 2016 19:07:03 +0100
Mel Gorman wrote:
> On Mon, Apr 11, 2016 at 06:19:07PM +0200, Jesper Dangaard Brouer wrote:
> > > http://git.kernel.org/cgit/linux/kernel/git/mel/linux.git/log/?h=mm-vmscan-node-lru-v4r5
> > >
> >
> > The cost decreased to: 228 cycles(tsc), but there are som
On 04/11/2016 11:37 AM, Jesper Dangaard Brouer wrote:
On Mon, 11 Apr 2016 14:46:25 -0300
Thadeu Lima de Souza Cascardo wrote:
So, Jesper, please take into consideration that this pool design
would rather be per device. Otherwise, we allow some device to write
into another's device/driver memor
On Mon, 11 Apr 2016 14:46:25 -0300
Thadeu Lima de Souza Cascardo wrote:
> So, Jesper, please take into consideration that this pool design
> would rather be per device. Otherwise, we allow some device to write
> into another's device/driver memory.
Yes, that was my intended use. I want to have
On Mon, Apr 11, 2016 at 06:19:07PM +0200, Jesper Dangaard Brouer wrote:
> > http://git.kernel.org/cgit/linux/kernel/git/mel/linux.git/log/?h=mm-vmscan-node-lru-v4r5
> >
>
> The cost decreased to: 228 cycles(tsc), but there are some variations,
> sometimes it increase to 238 cycles(tsc).
>
In th
On Mon, Apr 11, 2016 at 12:20:47PM -0400, Matthew Wilcox wrote:
> On Mon, Apr 11, 2016 at 02:08:27PM +0100, Mel Gorman wrote:
> > On Mon, Apr 11, 2016 at 02:26:39PM +0200, Jesper Dangaard Brouer wrote:
> > > On arch's like PowerPC, the DMA API is the bottleneck. To workaround
> > > the cost of DMA
On Mon, 2016-04-11 at 18:19 +0200, Jesper Dangaard Brouer wrote:
> Drivers also do tricks where they fallback to smaller order pages. E.g.
> lookup function mlx4_alloc_pages(). I've tried to simulate that
> function here:
> https://github.com/netoptimizer/prototype-kernel/blob/91d323fc53/kernel/m
On Mon, Apr 11, 2016 at 02:08:27PM +0100, Mel Gorman wrote:
> On Mon, Apr 11, 2016 at 02:26:39PM +0200, Jesper Dangaard Brouer wrote:
> > On arch's like PowerPC, the DMA API is the bottleneck. To workaround
> > the cost of DMA calls, NIC driver alloc large order (compound) pages.
> > (dma_map comp
On Mon, 11 Apr 2016 14:08:27 +0100 Mel Gorman
wrote:
> On Mon, Apr 11, 2016 at 02:26:39PM +0200, Jesper Dangaard Brouer wrote:
[...]
> >
> > It is always great if you can optimized the page allocator. IMHO the
> > page allocator is too slow.
>
> It's why I spent some time on it as any impro
On Mon, Apr 11, 2016 at 02:26:39PM +0200, Jesper Dangaard Brouer wrote:
> > Which bottleneck dominates -- the page allocator or the DMA API when
> > setting up coherent pages?
> >
>
> It is actually both, but mostly DMA on non-x86 archs. The need to
> support multiple archs, then also cause a slo
On Mon, 11 Apr 2016 09:58:19 +0100 Mel Gorman wrote:
> On Thu, Apr 07, 2016 at 04:17:15PM +0200, Jesper Dangaard Brouer wrote:
> > (Topic proposal for MM-summit)
> >
> > Network Interface Cards (NIC) drivers, and increasing speeds stress
> > the page-allocator (and DMA APIs). A number of driv
On Thu, Apr 07, 2016 at 04:17:15PM +0200, Jesper Dangaard Brouer wrote:
> (Topic proposal for MM-summit)
>
> Network Interface Cards (NIC) drivers, and increasing speeds stress
> the page-allocator (and DMA APIs). A number of driver specific
> open-coded approaches exists that work-around these b
This is also very interesting for storage targets, which face the same
issue. SCST has a mode where it caches some fully constructed SGLs,
which is probably very similar to what NICs want to do.
I think a cached allocator for page sets + the scatterlists that
describe these page sets would no
On Sat, 2016-04-09 at 11:11 +0200, Jesper Dangaard Brouer wrote:
> Hi Eric,
> Above code is okay. But do you think we also can get away with the same
> trick we do with the SKB refcnf? Where we avoid an atomic operation if
> refcnt==1.
>
> void kfree_skb(struct sk_buff *skb)
> {
> if (un
Hi Eric,
On Thu, 07 Apr 2016 08:18:29 -0700
Eric Dumazet wrote:
> On Thu, 2016-04-07 at 16:17 +0200, Jesper Dangaard Brouer wrote:
> > (Topic proposal for MM-summit)
> >
> > Network Interface Cards (NIC) drivers, and increasing speeds stress
> > the page-allocator (and DMA APIs). A number of d
On Thu, Apr 7, 2016 at 1:38 PM, Jesper Dangaard Brouer
wrote:
> On Thu, 7 Apr 2016 19:48:50 +
> "Waskiewicz, PJ" wrote:
>
>> On Thu, 2016-04-07 at 16:17 +0200, Jesper Dangaard Brouer wrote:
>> > (Topic proposal for MM-summit)
>> >
>> > Network Interface Cards (NIC) drivers, and increasing spe
On Thu, 7 Apr 2016 19:48:50 +
"Waskiewicz, PJ" wrote:
> On Thu, 2016-04-07 at 16:17 +0200, Jesper Dangaard Brouer wrote:
> > (Topic proposal for MM-summit)
> >
> > Network Interface Cards (NIC) drivers, and increasing speeds stress
> > the page-allocator (and DMA APIs). A number of driver s
On Thu, 2016-04-07 at 16:17 +0200, Jesper Dangaard Brouer wrote:
> (Topic proposal for MM-summit)
>
> Network Interface Cards (NIC) drivers, and increasing speeds stress
> the page-allocator (and DMA APIs). A number of driver specific
> open-coded approaches exists that work-around these bottlene
On Thu, 07 Apr 2016 12:14:00 -0400 Rik van Riel wrote:
> On Thu, 2016-04-07 at 08:48 -0700, Chuck Lever wrote:
> > >
> > > On Apr 7, 2016, at 7:38 AM, Christoph Hellwig
> > > wrote:
> > >
> > > This is also very interesting for storage targets, which face the
> > > same issue. SCST has a mod
On 04/07/16 07:38, Christoph Hellwig wrote:
This is also very interesting for storage targets, which face the same
issue. SCST has a mode where it caches some fully constructed SGLs,
which is probably very similar to what NICs want to do.
I think a cached allocator for page sets + the scatterl
On Thu, 2016-04-07 at 08:48 -0700, Chuck Lever wrote:
> >
> > On Apr 7, 2016, at 7:38 AM, Christoph Hellwig
> > wrote:
> >
> > This is also very interesting for storage targets, which face the
> > same
> > issue. SCST has a mode where it caches some fully constructed
> > SGLs,
> > which is prob
> On Apr 7, 2016, at 7:38 AM, Christoph Hellwig wrote:
>
> This is also very interesting for storage targets, which face the same
> issue. SCST has a mode where it caches some fully constructed SGLs,
> which is probably very similar to what NICs want to do.
+1 for NFS server.
--
Chuck Lever
On Thu, 2016-04-07 at 16:17 +0200, Jesper Dangaard Brouer wrote:
> (Topic proposal for MM-summit)
>
> Network Interface Cards (NIC) drivers, and increasing speeds stress
> the page-allocator (and DMA APIs). A number of driver specific
> open-coded approaches exists that work-around these bottlene
This is also very interesting for storage targets, which face the same
issue. SCST has a mode where it caches some fully constructed SGLs,
which is probably very similar to what NICs want to do.
(Topic proposal for MM-summit)
Network Interface Cards (NIC) drivers, and increasing speeds stress
the page-allocator (and DMA APIs). A number of driver specific
open-coded approaches exists that work-around these bottlenecks in the
page allocator and DMA APIs. E.g. open-coded recycle mechanisms,
35 matches
Mail list logo
