From: Martin Dalecki <dalecki@evision-ventures.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
dent@cosy.sbg.ac.at, adilger@clusterfs.com, da-x@gmx.net,
patch@luckynet.dynu.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.5.21 - list.h cleanup
Date: Tue, 11 Jun 2002 11:04:16 +0200 [thread overview]
Message-ID: <3D05BD10.106@evision-ventures.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0206110128130.1987-100000@home.transmeta.com>
> And while I'd like to avoid #include hell, I'm not willing to replace
> inline functions with #define's to avoid it ;^p
A more real example from blk.h:
extern inline struct request *elv_next_request(request_queue_t *q)
{
struct request *rq;
while ((rq = __elv_next_request(q))) {
rq->flags |= REQ_STARTED;
if (&rq->queuelist == q->last_merge)
q->last_merge = NULL;
if ((rq->flags & REQ_DONTPREP) || !q->prep_rq_fn)
break;
/*
* all ok, break and return it
*/
if (!q->prep_rq_fn(q, rq))
break;
/*
* prep said no-go, kill it
*/
blkdev_dequeue_request(rq);
if (end_that_request_first(rq, 0, rq->nr_sectors))
BUG();
end_that_request_last(rq);
}
return rq;
}
The only thing this achvies is kernel bload, since
elv_next_request is:
1. Calling tons of functions, which could be inlined as well.
2. Not precisely on any ultra fast path.
3. Bound by the device speed.
4. Increasing the pressure on branch prediction due
to the while construct.
next prev parent reply other threads:[~2002-06-11 9:04 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-09 11:09 [PATCH][2.5] introduce list_move macros Lightweight patch manager
2002-06-09 11:23 ` Mark Zealey
2002-06-10 14:17 ` Thunder from the hill
2002-06-09 11:48 ` OGAWA Hirofumi
2002-06-09 12:02 ` Thomas 'Dent' Mirlacher
2002-06-09 12:01 ` Russell King
2002-06-09 12:42 ` [PATCH][2.5] introduce list_move macros (revisited) Lightweight patch manager
2002-06-10 15:14 ` Dan Aloni
2002-06-10 15:28 ` [PATCH] 2.5.21 - list.h cleanup Dan Aloni
2002-06-10 15:45 ` Thunder from the hill
2002-06-10 16:37 ` Andreas Dilger
2002-06-10 16:50 ` Thomas 'Dent' Mirlacher
2002-06-10 17:02 ` Linus Torvalds
2002-06-10 17:07 ` Thomas 'Dent' Mirlacher
2002-06-10 17:21 ` Linus Torvalds
2002-06-11 8:00 ` Rusty Russell
2002-06-11 8:33 ` Linus Torvalds
2002-06-11 8:48 ` Martin Dalecki
2002-06-11 9:04 ` Martin Dalecki [this message]
2002-06-11 9:14 ` Rusty Russell
2002-06-12 19:45 ` Ingo Molnar
2002-06-13 5:51 ` Rusty Russell
2002-06-13 14:18 ` Ingo Molnar
2002-06-11 14:52 ` george anzinger
2002-06-11 16:03 ` Daniel Phillips
2002-06-12 1:10 ` Rusty Russell
2002-06-12 1:29 ` Linus Torvalds
2002-06-12 6:02 ` Rusty Russell
2002-06-12 7:11 ` Martin Dalecki
2002-06-12 7:27 ` Andrew Morton
2002-06-11 17:54 ` Gerrit Huizenga
2002-06-12 3:49 ` Rusty Russell
2002-06-12 17:30 ` Gerrit Huizenga
2002-06-10 17:26 ` Manik Raina
2002-06-10 17:51 ` Dan Aloni
2002-06-10 21:28 ` Thunder from the hill
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=3D05BD10.106@evision-ventures.com \
--to=dalecki@evision-ventures.com \
--cc=adilger@clusterfs.com \
--cc=da-x@gmx.net \
--cc=dent@cosy.sbg.ac.at \
--cc=linux-kernel@vger.kernel.org \
--cc=patch@luckynet.dynu.com \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@transmeta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox