From: Robert Love <rml@tech9.net>
To: mingo@elte.hu
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] proc-based cpu affinity user interface
Date: 27 Nov 2001 15:44:53 -0500 [thread overview]
Message-ID: <1006893895.815.0.camel@phantasy> (raw)
In-Reply-To: <Pine.LNX.4.33.0111271247120.9992-100000@localhost.localdomain>
In-Reply-To: <Pine.LNX.4.33.0111271247120.9992-100000@localhost.localdomain>
On Tue, 2001-11-27 at 06:52, Ingo Molnar wrote:
> two comments. First, this has already been done - Andrew Morton has
> written such a patch.
I didn't know this until after I started, but it is irrelevant. Use
Andrew's if you want. However, I have incorporated some useful bits
from your patch and such that I think are superior.
> Second, as i've repeatedly said it, it's a failure to do this over /proc.
> What if /proc is not mounted? What if the process is in a chroot()
> environment, should it not be able to set its own affinity? This is a
> fundamental limitation of your approach, and *if* we want to export the
> cpus_allowed affinity to user-space (which is up to discussion), then the
> right way (TM) to do it is via a syscall.
OK OK OK ... we can argue all day over syscall vs. proc. Personally, I
don't find any of the arguments fruitful -- we make all sorts of
restrictions and "Don't do thats" in the kernel. Requiring procfs isn't
the end of the world.
When you posted your initial patch, I commented I liked it but was
interested in a proc variant. Some people were interested. Even you
said it wasn't a huge deal.
It doesn't matter to me, let's just expose _some_ interface to
userspace. Personally, I prefer procfs, but both implementations are
nicely done. I respect you too much to argue religion like this. I'll
push for either variant.
Robert Love
next prev parent reply other threads:[~2001-11-27 20:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-27 3:31 [PATCH] proc-based cpu affinity user interface Robert Love
2001-11-27 3:52 ` Davide Libenzi
2001-11-27 4:14 ` Robert Love
2001-11-27 4:39 ` Davide Libenzi
2001-11-27 4:48 ` Davide Libenzi
2001-11-27 14:17 ` Ingo Molnar
2001-11-27 16:49 ` Davide Libenzi
2001-11-27 18:46 ` Ingo Molnar
2001-11-27 4:37 ` Anton Blanchard
2001-11-27 5:08 ` Robert Love
2001-11-27 5:42 ` Tim Hockin
2001-11-27 6:25 ` Andreas Dilger
2001-11-27 6:40 ` Robert Love
2001-11-27 11:52 ` Ingo Molnar
2001-11-27 10:10 ` Alan Cox
2001-11-27 14:21 ` Ingo Molnar
2001-11-27 20:44 ` Robert Love [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-11-27 20:23 Matthew Dobson
2001-12-10 8:33 ` Albert D. Cahalan
2001-12-10 8:40 ` Robert Love
2001-12-10 9:37 ` Albert D. Cahalan
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=1006893895.815.0.camel@phantasy \
--to=rml@tech9.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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.