From: Tim Walberg <tewalberg@mediaone.net>
To: linux-kernel@vger.kernel.org
Subject: Re: kernel/sched.c questions
Date: Wed, 4 Apr 2001 15:08:33 -0500 [thread overview]
Message-ID: <20010404150833.C28474@mediaone.net> (raw)
In-Reply-To: <A0C675E9DC2CD411A5870040053AEBA028416D@MAINSERVER>
In-Reply-To: <A0C675E9DC2CD411A5870040053AEBA028416D@MAINSERVER> from Sardañons, Eliel on 04/04/2001 14:52
[-- Attachment #1: Type: text/plain, Size: 2426 bytes --]
On 04/04/2001 16:52 -0300, Sardañons, Eliel wrote:
>> Hello, I would like to know why you put this two functions:
>> void scheduling_functions_start_here(void) { }
>> ...
>> void scheduling_functions_end_here(void) { }
>>
That one I have no idea about - maybe some perverse sort
of comment? Or maybe something somewhere needs to know the
address range that some functions lie within, and these functions
would delimit that range. Of course, that presumes that the
compiler in use doesn't reorder functions in the object code
that emits, but I think that's a fairly safe assumption for
now...
>> why you put 'case TASK_RUNNING'
>>
>> switch (prev->state) {
>> case TASK_INTERRUPTIBLE:
>> if (signal_pending(prev)) {
>> prev->state = TASK_RUNNING;
>> break;
>> }
>> default:
>> del_from_runqueue(prev);
>> case TASK_RUNNING:
>> }
>>
This just indicates that there is nothing to be done for the
TASK_RUNNING case - if it were left out, the default case would
be taken. Of course, a 'case TASK_RUNNING: break;' placed earlier
in the switch construct would be semantically the same, but there
may be reasons related to code optimization that this was done the
way it was.
>> and the last one:
>>
>> in the function schedule() you always use this syntax:
>>
>> -----
>> if (a_condition)
>> goto bebe;
>> bebe_back
>>
>>
>> bebe:
>> do_bebe();
>> goto bebe_back;
>> ------
>> why not just doing:
>>
>> if (a_condition)
>> do_bebe();
>>
>>
>> I know that goto's are better but finaly you are jumping to a function and
>> then calling the function. I think you can improve performance doing this.
This looks like a hand-optimization to avoid a branch in the most common
case. Chances are a_condition is supposed to be pretty rare, and the code
you suggest would usually include a branch for the usual code path, then.
tw
--
+--------------------------+------------------------------+
| Tim Walberg | tewalberg@mediaone.net |
| 828 Marshall Ct. | www.concentric.net/~twalberg |
| Palatine, IL 60074 | |
+--------------------------+------------------------------+
[-- Attachment #2: Type: application/pgp-signature, Size: 175 bytes --]
next prev parent reply other threads:[~2001-04-04 20:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-04 19:52 kernel/sched.c questions Sardañons, Eliel
2001-04-04 20:08 ` Tim Walberg [this message]
2001-04-04 20:20 ` Andi Kleen
2001-04-04 20:21 ` Bjorn Wesen
2001-04-04 21:22 ` Richard B. Johnson
2001-04-04 20:29 ` Stuart MacDonald
2001-04-05 20:28 ` Steven Walter
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=20010404150833.C28474@mediaone.net \
--to=tewalberg@mediaone.net \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox