[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151120175151.GA13966@amt.cnet>
Date: Fri, 20 Nov 2015 15:51:52 -0200
From: Marcelo Tosatti <mtosatti@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
Luiz Capitulino <lcapitulino@...hat.com>,
Vikas Shivappa <vikas.shivappa@...el.com>,
Tejun Heo <tj@...nel.org>, Yu Fenghua <fenghua.yu@...el.com>
Subject: Re: [RFD] CAT user space interface revisited
On Fri, Nov 20, 2015 at 08:53:34AM +0100, Thomas Gleixner wrote:
> On Thu, 19 Nov 2015, Marcelo Tosatti wrote:
> > On Thu, Nov 19, 2015 at 10:09:03AM +0100, Thomas Gleixner wrote:
> > > On Wed, 18 Nov 2015, Marcelo Tosatti wrote
> > > > Actually, there is a point that is useful: you might want the important
> > > > application to share the L3 portion with HW (that HW DMAs into), and
> > > > have only the application and the HW use that region.
> > > >
> > > > So its a good point that controlling the exact position of the reservation
> > > > is important.
> > >
> > > I'm glad you figured that out yourself. :)
> > >
> > > Thanks,
> > >
> > > tglx
> >
> > The HW is a reclaimer of the L3 region shared with HW.
> >
> > You might want to remove any threads from reclaiming from
> > that region.
>
> I might for some threads, but certainly not for those which need to
> access DMA buffers.
Yes, when i wrote "its a good point that controlling the exact position
of the reservation is important" i had that in mind as well.
But its wrong: not having a bit set in the CBM for the portion of L3
cache which is shared with HW only means "for cacheline misses of the
application, evict cachelines from this portion".
So yes, you might want to exclude the application which accesses DMA
buffers from reclaiming cachelines in the portion shared with HW,
to keep those cachelines longer in L3.
> Throwing away 10% of L3 just because you don't
> want to deal with it at the interface level is hillarious.
If there is interest on per-application configuration then it can
be integrated as well.
Thanks for your time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists