From: Peter Williams <pwil3058@bigpond.net.au>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: Con Kolivas <kernel@kolivas.org>,
Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>,
Zwane Mwaikambo <zwane@linuxpower.ca>
Subject: Re: [PATCH] staircase scheduler v6.4 for 2.6.7-rc3
Date: Wed, 09 Jun 2004 09:56:23 +1000 [thread overview]
Message-ID: <40C65227.7030301@bigpond.net.au> (raw)
In-Reply-To: <20040608233610.GC1444@holomorphy.com>
William Lee Irwin III wrote:
> On Wed, Jun 09, 2004 at 09:04:23AM +1000, Peter Williams wrote:
>
>>There was no need to add the extra overhead of a flag to indicate that a
>>task was queued for scheduling. Testing whether run_list is empty
>>achieves the same thing as reliably as the old array == NULL test did.
>
>
> Overhead? Doubtful. Also, that requires the use of list_del_init()
Yes, that's true.
> while dequeueing, which is not in place now. Please do back the claim
> with measurements. It should be easy enough to nop out set_task_queued(),
> implement task_queued() via !list_empty(), and clear_task_queued() via
> INIT_LIST_HEAD() for a quick performance comparison. But I'd say to
> merge it even if there's no difference, as it's more self-contained.
>
Since the principle use of testing array for NULL or not was to find out
if the task was on a run list it seems silly to have a flag to determine
this. All it does is provide an opportunity for the flag to not
accurately reflect whether the task is really on a list or not.
It caused the number of files touched by the staircase patch to increase
by a factor of five which is another good reason to use the alternative.
Peter
--
Dr Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
prev parent reply other threads:[~2004-06-08 23:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-08 14:23 [PATCH] staircase scheduler v6.4 for 2.6.7-rc3 Con Kolivas
2004-06-08 23:04 ` Peter Williams
2004-06-08 23:36 ` William Lee Irwin III
2004-06-08 23:56 ` Peter Williams [this message]
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=40C65227.7030301@bigpond.net.au \
--to=pwil3058@bigpond.net.au \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wli@holomorphy.com \
--cc=zwane@linuxpower.ca \
/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.