On 01/11/21 15:04, Peter Zijlstra wrote:
> On Mon, Jan 04, 2021 at 06:26:42PM +, Qais Yousef wrote:
>
> > So I have a proper patch for that now, that actually turned out to be really
> > tiny once you untangle exactly what is missing.
> >
> > Peter, bpf programs aren't considered ABIs AFAIK,
On Mon, Jan 04, 2021 at 06:26:42PM +, Qais Yousef wrote:
> So I have a proper patch for that now, that actually turned out to be really
> tiny once you untangle exactly what is missing.
>
> Peter, bpf programs aren't considered ABIs AFAIK, do you have concerns about
> that?
In order to use
On 01/06/21 15:42, Andrii Nakryiko wrote:
> On Wed, Jan 6, 2021 at 3:27 AM Qais Yousef wrote:
> >
> > On 01/05/21 08:44, Alexei Starovoitov wrote:
> > > > Any pointer to an example test I could base this on?
> > >
> > > selftests/bpf/
> >
> > I was hoping for something more elaborate. I thought
On Wed, Jan 6, 2021 at 3:27 AM Qais Yousef wrote:
>
> On 01/05/21 08:44, Alexei Starovoitov wrote:
> > > Any pointer to an example test I could base this on?
> >
> > selftests/bpf/
>
> I was hoping for something more elaborate. I thought there's something already
> there that do some verification
On 01/05/21 08:44, Alexei Starovoitov wrote:
> > Any pointer to an example test I could base this on?
>
> selftests/bpf/
I was hoping for something more elaborate. I thought there's something already
there that do some verification for raw tracepoint that I could either extend
or replicate.
On Tue, Jan 5, 2021 at 3:39 AM Qais Yousef wrote:
>
> On 01/04/21 10:59, Alexei Starovoitov wrote:
> > > > > I did have a patch that allowed that. It might be worth trying to
> > > > > upstream it.
> > > > > It just required a new macro which could be problematic.
> > > > >
> > > > >
On 01/04/21 10:59, Alexei Starovoitov wrote:
> > > > I did have a patch that allowed that. It might be worth trying to
> > > > upstream it.
> > > > It just required a new macro which could be problematic.
> > > >
> > > >
On Mon, Jan 4, 2021 at 10:29 AM Qais Yousef wrote:
>
> On 09/08/20 09:19, Phil Auld wrote:
> > Hi Quais,
> >
> > On Mon, Sep 07, 2020 at 12:02:24PM +0100 Qais Yousef wrote:
> > > On 09/02/20 09:54, Phil Auld wrote:
> > > > >
> > > > > I think this decoupling is not necessary. The natural place
On 09/08/20 09:19, Phil Auld wrote:
> Hi Quais,
>
> On Mon, Sep 07, 2020 at 12:02:24PM +0100 Qais Yousef wrote:
> > On 09/02/20 09:54, Phil Auld wrote:
> > > >
> > > > I think this decoupling is not necessary. The natural place for those
> > > > scheduler trace_event based on trace_points
On 09/07/20 13:13, pet...@infradead.org wrote:
> On Mon, Sep 07, 2020 at 11:48:45AM +0100, Qais Yousef wrote:
> > IMHO the above is a hack. Out-of-tree modules should rely on public headers
> > and
> > exported functions only. What you propose means that people who want to use
> > these
On 09/08/20 09:19, Phil Auld wrote:
> Hi Quais,
>
> On Mon, Sep 07, 2020 at 12:02:24PM +0100 Qais Yousef wrote:
> > On 09/02/20 09:54, Phil Auld wrote:
> > > >
> > > > I think this decoupling is not necessary. The natural place for those
> > > > scheduler trace_event based on trace_points
On 09/08/20 13:17, Dietmar Eggemann wrote:
> On 07/09/2020 16:51, Qais Yousef wrote:
> > On 09/07/20 13:13, pet...@infradead.org wrote:
> >> On Mon, Sep 07, 2020 at 11:48:45AM +0100, Qais Yousef wrote:
> >>> IMHO the above is a hack. Out-of-tree modules should rely on public
> >>> headers and
>
On 08/09/2020 17:17, Qais Yousef wrote:
> On 09/08/20 13:17, Dietmar Eggemann wrote:
>> On 07/09/2020 16:51, Qais Yousef wrote:
>>> On 09/07/20 13:13, pet...@infradead.org wrote:
On Mon, Sep 07, 2020 at 11:48:45AM +0100, Qais Yousef wrote:
> IMHO the above is a hack. Out-of-tree modules
Hi Quais,
On Mon, Sep 07, 2020 at 12:02:24PM +0100 Qais Yousef wrote:
> On 09/02/20 09:54, Phil Auld wrote:
> > >
> > > I think this decoupling is not necessary. The natural place for those
> > > scheduler trace_event based on trace_points extension files is
> > > kernel/sched/ and here the
On 07/09/2020 16:51, Qais Yousef wrote:
> On 09/07/20 13:13, pet...@infradead.org wrote:
>> On Mon, Sep 07, 2020 at 11:48:45AM +0100, Qais Yousef wrote:
>>> IMHO the above is a hack. Out-of-tree modules should rely on public headers
>>> and
>>> exported functions only. What you propose means that
On 09/02/20 09:54, Phil Auld wrote:
> >
> > I think this decoupling is not necessary. The natural place for those
> > scheduler trace_event based on trace_points extension files is
> > kernel/sched/ and here the internal sched.h can just be included.
> >
> > If someone really wants to build this
On Mon, Sep 07, 2020 at 11:48:45AM +0100, Qais Yousef wrote:
> IMHO the above is a hack. Out-of-tree modules should rely on public headers
> and
> exported functions only. What you propose means that people who want to use
> these tracepoints in meaningful way must have a prebuilt kernel handy.
On 09/07/20 13:13, pet...@infradead.org wrote:
> On Mon, Sep 07, 2020 at 11:48:45AM +0100, Qais Yousef wrote:
> > IMHO the above is a hack. Out-of-tree modules should rely on public headers
> > and
> > exported functions only. What you propose means that people who want to use
> > these
Hi Dietmar
On 09/02/20 12:44, Dietmar Eggemann wrote:
> + Phil Auld
>
> On 28/08/2020 19:26, Qais Yousef wrote:
> > On 08/28/20 19:10, Dietmar Eggemann wrote:
> >> On 28/08/2020 12:27, Qais Yousef wrote:
> >>> On 08/28/20 10:00, vincent.donnef...@arm.com wrote:
> From: Vincent Donnefort
>
On Wed, Sep 02, 2020 at 12:44:42PM +0200 Dietmar Eggemann wrote:
> + Phil Auld
>
Thanks Dietmar.
> On 28/08/2020 19:26, Qais Yousef wrote:
> > On 08/28/20 19:10, Dietmar Eggemann wrote:
> >> On 28/08/2020 12:27, Qais Yousef wrote:
> >>> On 08/28/20 10:00, vincent.donnef...@arm.com wrote:
>
+ Phil Auld
On 28/08/2020 19:26, Qais Yousef wrote:
> On 08/28/20 19:10, Dietmar Eggemann wrote:
>> On 28/08/2020 12:27, Qais Yousef wrote:
>>> On 08/28/20 10:00, vincent.donnef...@arm.com wrote:
From: Vincent Donnefort
[...]
>> Can you remind me why we have all these helper functions
On 08/28/20 19:10, Dietmar Eggemann wrote:
> On 28/08/2020 12:27, Qais Yousef wrote:
> > On 08/28/20 10:00, vincent.donnef...@arm.com wrote:
> >> From: Vincent Donnefort
> >>
> >> rq->cpu_capacity is a key element in several scheduler parts, such as EAS
> >> task placement and load balancing.
On 28/08/2020 12:27, Qais Yousef wrote:
> On 08/28/20 10:00, vincent.donnef...@arm.com wrote:
>> From: Vincent Donnefort
>>
>> rq->cpu_capacity is a key element in several scheduler parts, such as EAS
>> task placement and load balancing. Tracking this value enables testing
>> and/or debugging by
On 08/28/20 10:00, vincent.donnef...@arm.com wrote:
> From: Vincent Donnefort
>
> rq->cpu_capacity is a key element in several scheduler parts, such as EAS
> task placement and load balancing. Tracking this value enables testing
> and/or debugging by a toolkit.
>
> Signed-off-by: Vincent
24 matches
Mail list logo
