From: Ingo Molnar <mingo@elte.hu>
To: Helge Hafting <helgehaf@aitel.hist.no>
Cc: linux-kernel@vger.kernel.org
Subject: Re: sched_setaffinity usability
Date: Sun, 21 Mar 2004 10:51:16 +0100 [thread overview]
Message-ID: <20040321095116.GA7721@elte.hu> (raw)
In-Reply-To: <405AB72B.4030204@aitel.hist.no>
* Helge Hafting <helgehaf@aitel.hist.no> wrote:
> Let the compile create that info file. Then handle it much like a
> module, except that it is a "module" without any code. I.e. copy it
> to /lib/modules/<kernelversion> if installing modules, or stuff the
> file into the initrd if making an initrd.
>
> Now it is in a place specific to the kernel, where a library can find
> it.
this has a couple of disadvantages:
- the kernel can pre-map the 'file' cheaper - in fact on x86 it's
zero-cost currently. Mapping a file takes 3 syscalls and at least one
pagefault. Since glibc needs a good portion of this info for
absolutely every ELF binary, why not provide it in a preconstructed
way? x86 is doing it via the VDSO. ia64 and x86-64 is doing it via a
dso-alike mechanism.
- obtaining the kernel version currently needs one more syscall
[uname()].
- the 'metadata' becomes detached from the kernel image, so it
cannot contain 'crutial' data. Testing kernels becomes harder, etc.
(until now i could just send a bzImage to someone to get it tested -
now it would have to include the metadata too.)
- it excludes non-build-time data.
Ingo
next prev parent reply other threads:[~2004-03-21 9:50 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-18 8:05 sched_setaffinity usability Ulrich Drepper
2004-03-18 8:12 ` Tim Hockin
2004-03-18 8:22 ` Ulrich Drepper
2004-03-18 8:47 ` Ulrich Drepper
2004-03-18 9:45 ` Andrew Morton
2004-03-18 10:10 ` Andrew Morton
2004-03-18 11:29 ` Ingo Molnar
2004-03-18 12:07 ` Christoph Hellwig
2004-03-18 12:31 ` Ingo Molnar
2004-03-19 8:05 ` Ulrich Drepper
2004-03-18 15:55 ` Linus Torvalds
2004-03-18 18:24 ` Ingo Molnar
2004-03-18 18:33 ` Andrew Morton
2004-03-18 18:39 ` Ingo Molnar
2004-03-18 18:55 ` Ingo Molnar
2004-03-18 20:01 ` Andrea Arcangeli
2004-03-18 20:28 ` Ingo Molnar
2004-03-18 20:49 ` David Lang
2004-03-18 20:57 ` Randy.Dunlap
2004-03-18 21:06 ` Ingo Molnar
2004-03-18 21:07 ` Davide Libenzi
2004-03-18 21:46 ` Ingo Molnar
2004-03-19 1:37 ` Davide Libenzi
2004-03-19 9:02 ` Helge Hafting
2004-03-21 9:51 ` Ingo Molnar [this message]
2004-03-19 0:00 ` Paul Jackson
2004-03-18 17:47 ` sched_setaffinity usability -- other issue Chris Friesen
[not found] <1B0Ls-lY-27@gated-at.bofh.it>
[not found] ` <1B42z-3Lx-5@gated-at.bofh.it>
[not found] ` <1B4Fh-4sQ-3@gated-at.bofh.it>
[not found] ` <1B86P-8gq-69@gated-at.bofh.it>
[not found] ` <1Bars-2s6-29@gated-at.bofh.it>
[not found] ` <1BaKU-2Lg-49@gated-at.bofh.it>
[not found] ` <1BaKX-2Lg-61@gated-at.bofh.it>
[not found] ` <1BaUR-2V0-41@gated-at.bofh.it>
2004-03-18 21:23 ` sched_setaffinity usability Andi Kleen
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=20040321095116.GA7721@elte.hu \
--to=mingo@elte.hu \
--cc=helgehaf@aitel.hist.no \
--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 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.