On 15.08.2017 20:28, Alexey Budankov wrote:
> Hi Peter,
>
> On 07.08.2017 10:17, Alexey Budankov wrote:
>> On 04.08.2017 17:36, Peter Zijlstra wrote:
>>> On Thu, Aug 03, 2017 at 11:30:09PM +0300, Alexey Budankov wrote:
On 03.08.2017 16:00, Peter Zijlstra wrote:
> On Wed, Aug 02, 2017 at 1
On 30.08.2017 14:16, Alexey Budankov wrote:
> On 30.08.2017 11:30, Alexey Budankov wrote:
>> On 29.08.2017 16:51, Alexander Shishkin wrote:
>>> Alexey Budankov writes:
>>>
Now I figured that not all indexed events are always located under
the root with the same cpu, and it depends on th
On 30.08.2017 11:30, Alexey Budankov wrote:
> On 29.08.2017 16:51, Alexander Shishkin wrote:
>> Alexey Budankov writes:
>>
>>> Now I figured that not all indexed events are always located under
>>> the root with the same cpu, and it depends on the order of insertion
>>> e.g. with insertion order
Alexey Budankov writes:
> On 30.08.2017 13:18, Alexander Shishkin wrote:
>> Alexey Budankov writes:
>>
> Iterating cpu specific subtree like this:
>
> #define for_each_group_event(event, group, cpu, pmu, field)\
> for (event = rb_entry_safe(group_first(group, cpu, pmu)
On 30.08.2017 13:18, Alexander Shishkin wrote:
> Alexey Budankov writes:
>
Iterating cpu specific subtree like this:
#define for_each_group_event(event, group, cpu, pmu, field) \
for (event = rb_entry_safe(group_first(group, cpu, pmu), \
Alexey Budankov writes:
>>> Iterating cpu specific subtree like this:
>>>
>>> #define for_each_group_event(event, group, cpu, pmu, field) \
>>> for (event = rb_entry_safe(group_first(group, cpu, pmu), \
>>>typeof(*event), field); \
>>> event &&
On 29.08.2017 16:51, Alexander Shishkin wrote:
> Alexey Budankov writes:
>
>> Now I figured that not all indexed events are always located under
>> the root with the same cpu, and it depends on the order of insertion
>> e.g. with insertion order 01,02,03,14,15,16 we get this:
>>
>> 02
>>
Alexey Budankov writes:
> Now I figured that not all indexed events are always located under
> the root with the same cpu, and it depends on the order of insertion
> e.g. with insertion order 01,02,03,14,15,16 we get this:
>
> 02
> / \
>01 14
> / \
> 03 15
>
On 23.08.2017 16:39, Alexander Shishkin wrote:
> Alexey Budankov writes:
>
>> bool event_less(left, right)
>> {
>> if (left->cpu < right->cpu)
>> return true;
>>
>> if (left->cpu > right_cpu)
>> return false;
>>
>> if (left->vtime < right->vtime)
Alexey Budankov writes:
> bool event_less(left, right)
> {
> if (left->cpu < right->cpu)
> return true;
>
> if (left->cpu > right_cpu)
> return false;
>
> if (left->vtime < right->vtime)
> return true;
>
> return false;
> }
>
Hi Peter,
On 07.08.2017 10:17, Alexey Budankov wrote:
> On 04.08.2017 17:36, Peter Zijlstra wrote:
>> On Thu, Aug 03, 2017 at 11:30:09PM +0300, Alexey Budankov wrote:
>>> On 03.08.2017 16:00, Peter Zijlstra wrote:
On Wed, Aug 02, 2017 at 11:13:54AM +0300, Alexey Budankov wrote:
>>
> +/*
>
On 07.08.2017 19:57, Peter Zijlstra wrote:
> On Mon, Aug 07, 2017 at 07:27:30PM +0300, Alexey Budankov wrote:
>> On 07.08.2017 18:55, Peter Zijlstra wrote:
>
>>> In the extreme, if you construct your program such that you'll never get
>>> hit by the tick (this used to be a popular measure to hide
On Mon, Aug 07, 2017 at 10:39:55AM -0700, Andi Kleen wrote:
> I'm not sure Alexey's patch kit will be able to solve every possible
> problem with the event scheduler. Trying to fix everything at
> the same time is usually difficult.
I didn't say he should solve this. Just said that putting every
On Mon, Aug 07, 2017 at 06:57:11PM +0200, Peter Zijlstra wrote:
> On Mon, Aug 07, 2017 at 07:27:30PM +0300, Alexey Budankov wrote:
> > On 07.08.2017 18:55, Peter Zijlstra wrote:
>
> > > In the extreme, if you construct your program such that you'll never get
> > > hit by the tick (this used to be
On Mon, Aug 07, 2017 at 07:27:30PM +0300, Alexey Budankov wrote:
> On 07.08.2017 18:55, Peter Zijlstra wrote:
> > In the extreme, if you construct your program such that you'll never get
> > hit by the tick (this used to be a popular measure to hide yourself from
> > time accounting)
>
> Well, so
On 07.08.2017 18:55, Peter Zijlstra wrote:
> On Mon, Aug 07, 2017 at 06:32:16PM +0300, Alexey Budankov wrote:
>> On 07.08.2017 12:13, Peter Zijlstra wrote:
>>> On Mon, Aug 07, 2017 at 10:39:13AM +0200, Peter Zijlstra wrote:
On Mon, Aug 07, 2017 at 10:17:46AM +0300, Alexey Budankov wrote:
>
On Mon, Aug 07, 2017 at 06:32:16PM +0300, Alexey Budankov wrote:
> On 07.08.2017 12:13, Peter Zijlstra wrote:
> > On Mon, Aug 07, 2017 at 10:39:13AM +0200, Peter Zijlstra wrote:
> >> On Mon, Aug 07, 2017 at 10:17:46AM +0300, Alexey Budankov wrote:
> >>> Makes sense. The implementation becomes a bit
On 07.08.2017 12:13, Peter Zijlstra wrote:
> On Mon, Aug 07, 2017 at 10:39:13AM +0200, Peter Zijlstra wrote:
>> On Mon, Aug 07, 2017 at 10:17:46AM +0300, Alexey Budankov wrote:
>>> Makes sense. The implementation becomes a bit simpler. The drawbacks
>>> may be several rotations of potentially big
On 04.08.2017 17:53, Peter Zijlstra wrote:
> On Thu, Aug 03, 2017 at 11:30:09PM +0300, Alexey Budankov wrote:
>> On 03.08.2017 16:00, Peter Zijlstra wrote:
>>> On Wed, Aug 02, 2017 at 11:13:54AM +0300, Alexey Budankov wrote:
>
@@ -2759,13 +2932,13 @@ static void ctx_sched_out(struct
per
On Mon, Aug 07, 2017 at 10:39:13AM +0200, Peter Zijlstra wrote:
> On Mon, Aug 07, 2017 at 10:17:46AM +0300, Alexey Budankov wrote:
> > Makes sense. The implementation becomes a bit simpler. The drawbacks
> > may be several rotations of potentially big tree on the critical path,
> > instead of upd
On Mon, Aug 07, 2017 at 10:17:46AM +0300, Alexey Budankov wrote:
> Makes sense. The implementation becomes a bit simpler. The drawbacks
> may be several rotations of potentially big tree on the critical path,
> instead of updating four pointers in case of the tree of lists.
Yes, but like said, i
On 04.08.2017 17:36, Peter Zijlstra wrote:
> On Thu, Aug 03, 2017 at 11:30:09PM +0300, Alexey Budankov wrote:
>> On 03.08.2017 16:00, Peter Zijlstra wrote:
>>> On Wed, Aug 02, 2017 at 11:13:54AM +0300, Alexey Budankov wrote:
>
+/*
+ * Find group list by a cpu key and rotate it.
+ */
On Thu, Aug 03, 2017 at 11:30:09PM +0300, Alexey Budankov wrote:
> On 03.08.2017 16:00, Peter Zijlstra wrote:
> > On Wed, Aug 02, 2017 at 11:13:54AM +0300, Alexey Budankov wrote:
> >> @@ -2759,13 +2932,13 @@ static void ctx_sched_out(struct
> >> perf_event_context *ctx,
> >>
> >>perf_pmu_di
On Thu, Aug 03, 2017 at 11:30:09PM +0300, Alexey Budankov wrote:
> On 03.08.2017 16:00, Peter Zijlstra wrote:
> > On Wed, Aug 02, 2017 at 11:13:54AM +0300, Alexey Budankov wrote:
> >> +/*
> >> + * Find group list by a cpu key and rotate it.
> >> + */
> >> +static void
> >> +perf_event_groups_rotat
On 03.08.2017 16:00, Peter Zijlstra wrote:
> On Wed, Aug 02, 2017 at 11:13:54AM +0300, Alexey Budankov wrote:
>> This patch moves event groups into rb tree sorted by CPU, so that
>> multiplexing hrtimer interrupt handler would be able skipping to the current
>> CPU's list and ignore groups alloca
On Wed, Aug 02, 2017 at 11:13:54AM +0300, Alexey Budankov wrote:
> This patch moves event groups into rb tree sorted by CPU, so that
> multiplexing hrtimer interrupt handler would be able skipping to the current
> CPU's list and ignore groups allocated for the other CPUs.
>
> New API for manipul
26 matches
Mail list logo
