[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151124082754.GB17000@pengc-linux.bj.intel.com>
Date: Tue, 24 Nov 2015 16:27:54 +0800
From: Chao Peng <chao.p.peng@...ux.intel.com>
To: Marcelo Tosatti <mtosatti@...hat.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
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 Wed, Nov 18, 2015 at 10:01:54PM -0200, Marcelo Tosatti wrote:
> > tglx
>
> Again: you don't need to look into the MSR table and relate it
> to tasks if you store the data as:
>
> task group 1 = {
> reservation-1 = {size = 80Kb, type = data, socketmask = 0xffff},
> reservation-2 = {size = 100Kb, type = code, socketmask = 0xffff}
> }
>
> task group 2 = {
> reservation-1 = {size = 80Kb, type = data, socketmask = 0xffff},
> reservation-3 = {size = 200Kb, type = code, socketmask = 0xffff}
> }
>
> Task group 1 and task group 2 share reservation-1.
Because there is only size but not CBM position info, I guess for
different reservations they will not overlap each other, right?
Personally I like this way of exposing minimal information to userspace.
I can think it working well except for one concern of losing flexibility:
For instance, there is a box for which the full CBM is 0xfffff. After
cache reservation creating/freeing for a while we then have reservations:
reservation1: 0xf0000
reservation2: 0x00ff0
Now people want to request a reservation which size is 0xff, so how
will kernel do at this time? It could return just error or do some
moving/merging (e.g. for reservation2: 0x00ff0 => 0x0ff00) and then
satisfy the request. But I don't know if the moving/merging will cause
delay for tasks that is using it.
Thanks,
Chao
--
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