From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/i915: Group the irq breadcrumb variables into the same cacheline
Date: Wed, 6 Jul 2016 10:47:58 +0100 [thread overview]
Message-ID: <577CD3CE.7000708@linux.intel.com> (raw)
In-Reply-To: <20160706093634.GI15134@nuc-i3427.alporthouse.com>
On 06/07/16 10:36, Chris Wilson wrote:
> On Wed, Jul 06, 2016 at 10:18:32AM +0100, Tvrtko Ursulin wrote:
>>
>> On 06/07/16 08:45, Chris Wilson wrote:
>>> As we inspect both the tasklet (to check for an active bottom-half) and
>>> set the irq-posted flag at the same time (both in the interrupt handler
>>> and then in the bottom-halt), group those two together into the same
>>> cacheline. (Not having total control over placement of the struct means
>>> we can't guarantee the cacheline boundary, we need to align the kmalloc
>>> and then each struct, but the grouping should help.)
>>
>> Any actual difference or just tidy?
>
> Just motivated by tidying. I expect this to be in the noise (but since I
> have the tools, I should check just in case).
>
>>> @@ -167,16 +167,20 @@ struct intel_engine_cs {
>>> * the overhead of waking that client is much preferred.
>>> */
>>> struct intel_breadcrumbs {
>>> + struct task_struct *irq_tasklet; /* bh for user interrupts */
>>
>> Tasklet was kind of passable, irq_tasklet is imho worse. I think
>> anyone who see that name would thing this handles interrupts of some
>> sort. :)
>
> My thinking was to give a similar name to the three variables used in
> the irq handler (and bottom-half) and move them aside from the spinlock.
>
>> How about first_wait_task ?
>>
>> I know it may feel like pointless bike-shedding and maybe it is so I
>> am leaving it with you.
>
> Similarity argument still holds imo.
>
> irq_seqno_bh ?
>
>>> + unsigned long irq_count;
>>> + bool irq_posted;
>>> +
>>> spinlock_t lock; /* protects the lists of requests */
>>> struct rb_root waiters; /* sorted by retirement, priority */
>>> struct rb_root signals; /* sorted by retirement */
>>> struct intel_wait *first_wait; /* oldest waiter by retirement */
>>> - struct task_struct *tasklet; /* bh for user interrupts */
>>> struct task_struct *signaler; /* used for fence signalling */
>>> struct drm_i915_gem_request *first_signal;
>>> struct timer_list fake_irq; /* used after a missed interrupt */
>>> - bool irq_enabled;
>>> - bool rpm_wakelock;
>>> +
>>> + bool irq_enabled : 1;
>>> + bool rpm_wakelock : 1;
>>
>> Is there much point in having bitfields? To me two plain bools would
>> be just fine and smaller code.
>
> In this case a fractionally smaller struct (-4 bytes)
> The code size in this case is identical
>
> text data bss dec hex
> 1067277 4565 416 1072258 105c82 as bool
> 1067277 4565 416 1072258 105c82 as bool : 1
>
> since we only do very simple test and sets.
Never mind then, leave it all as it was.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-07-06 9:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-06 7:45 [PATCH 1/3] drm/i915: Always double check for a missed interrupt for new bottom halves Chris Wilson
2016-07-06 7:45 ` [PATCH 2/3] drm/i915: Wake up the bottom-half if we steal their interrupt Chris Wilson
2016-07-06 9:31 ` Tvrtko Ursulin
2016-07-06 7:45 ` [PATCH 3/3] drm/i915: Group the irq breadcrumb variables into the same cacheline Chris Wilson
2016-07-06 9:18 ` Tvrtko Ursulin
2016-07-06 9:36 ` Chris Wilson
2016-07-06 9:47 ` Tvrtko Ursulin [this message]
2016-07-06 8:11 ` ✗ Ro.CI.BAT: failure for series starting with [1/3] drm/i915: Always double check for a missed interrupt for new bottom halves Patchwork
2016-07-06 8:26 ` [PATCH 1/3] " Chris Wilson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=577CD3CE.7000708@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.