From: Davidlohr Bueso <dave@stgolabs.net>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH 2/5] ipc/sem: rework task wakeups
Date: Sun, 18 Sep 2016 11:26:46 -0700 [thread overview]
Message-ID: <20160918182646.GA22474@linux-80c1.suse> (raw)
In-Reply-To: <c43262af-829d-5fd3-fe17-15c27a5edd14@colorfullife.com>
On Sun, 18 Sep 2016, Manfred Spraul wrote:
>>+ <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Why this empty line?
That's my fat fingers, will remove it.
>>+ }
>>+
>>+ sem_unlock(sma, locknum);
>>+ rcu_read_unlock();
>>+ wake_up_q(&wake_q);
>>+
>>+ goto out_free;
>> }
>>- if (error <= 0)
>>- goto out_unlock_free;
>I don't see the strategy:
>I've used the approach that cleanup is at the end, to reduce
>duplicated code, even if it means that error codepaths unnecessarily
>call wakeup for an empty list and that the list is always initialized.
>
>With patch 1 of the series, you start to optimize for that.
>Now this patch reintroduces some wake_up_q calls for error paths.
Well yes, but this is a much more self contained than what we currently have
in that at least perform_atomic_semop() was called. Yes, an error path will
still call wake_up_q unnecessarily, but its pretty obvious what's going on within
that error <= 0 condition. I really don't think this is a big deal. In addition
the general exit path of the function is also slightly cleaned up as a consequence.
>So: What is the aim?
>I would propose to skip patch 1 and leave the wake_up_q at the end.
>
>Or, if we really want to avoid the wakeup calls, then do it entirely.
>Perhaps:
>> if(error == 0) { /* nonblocking codepath 1, with wakeups */
>> [...]
>> }
>> if (error < 0} goto out_unlock_free;
>>
>This would have an advantage, because the WAKE_Q would be initialized
>only when needed
Sure. Note that we can even get picky with this in semctl calls, but I'm
ok with some unnecessary initialization and wake_up_q paths. Please shout
if you really want me to change them and I can add followup patches, although
I suspect you'll agree.
Thanks,
Davidlohr
next prev parent reply other threads:[~2016-09-18 18:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-12 11:53 [PATCH -next 0/5] ipc/sem: semop(2) improvements Davidlohr Bueso
2016-09-12 11:53 ` [PATCH 1/5] ipc/sem: do not call wake_sem_queue_do() prematurely Davidlohr Bueso
2016-09-13 4:17 ` Manfred Spraul
2016-09-13 8:14 ` Davidlohr Bueso
2016-09-12 11:53 ` [PATCH 2/5] ipc/sem: rework task wakeups Davidlohr Bueso
2016-09-13 18:04 ` Manfred Spraul
2016-09-14 15:45 ` Davidlohr Bueso
2016-09-18 14:37 ` Manfred Spraul
2016-09-18 18:26 ` Davidlohr Bueso [this message]
2016-09-12 11:53 ` [PATCH 3/5] ipc/sem: optimize perform_atomic_semop() Davidlohr Bueso
2016-09-12 17:56 ` Manfred Spraul
2016-09-13 8:33 ` Davidlohr Bueso
2016-09-19 4:41 ` Manfred Spraul
2016-09-12 11:53 ` [PATCH 4/5] ipc/sem: explicitly inline check_restart Davidlohr Bueso
2016-09-12 11:53 ` [PATCH 5/5] ipc/sem: use proper list api for pending_list wakeups Davidlohr Bueso
2016-09-18 17:51 ` Manfred Spraul
-- strict thread matches above, loose matches on Subject: below --
2016-09-18 19:11 [PATCH -next v2 0/5] ipc/sem: semop(2) improvements Davidlohr Bueso
2016-09-18 19:11 ` [PATCH 2/5] ipc/sem: rework task wakeups Davidlohr Bueso
2016-09-19 18:26 ` Manfred Spraul
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=20160918182646.GA22474@linux-80c1.suse \
--to=dave@stgolabs.net \
--cc=akpm@linux-foundation.org \
--cc=dbueso@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
/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.