public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Ulrich Drepper <drepper@redhat.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>
Subject: Re: sched_setaffinity usability
Date: Thu, 18 Mar 2004 12:29:13 +0100	[thread overview]
Message-ID: <20040318112913.GA13981@elte.hu> (raw)
In-Reply-To: <40595842.5070708@redhat.com>


* Ulrich Drepper <drepper@redhat.com> wrote:

> The sched_setaffinity syscall currently has a usability problem.  The
> size of cpumask_t is not visible outside the kernel and might change
> from kernel to kernel.  So, if the user uses a large CPU bitset and
> passes it to the kernel it is not known at all whether all the bits
> provided in the bitmap are used.  The kernel simply copies the first
> bytes, enough to fill in the cpumask_t object and ignores the rest.
> 
> A simple check for a too large bitset is not good.  Programs which are
> portable (to different kernels) and future safe should use large
> bitmap sizes.  Instead the user should only be notified about the size
> problem if any nonzero bit is ignored.

how about adding a new syscall, sys_sched_get_affinity_span(), which
would be called by glibc first time one of the affinity syscalls are
called.

This syscall would be a prime target to be optimized away via the
vsyscall DSO, so there's no overhead worry.

something like the attached patch.

or, maybe it would be better to introduce some sort of 'system
constants' syscall that would be a generic umbrella for such things -
and could easily be converted into a vsyscall. Or we could make it part
of the .data section of the VDSO - thus no copying overhead, only one
symbol lookup.

	Ingo

--- linux/arch/i386/kernel/entry.S.orig
+++ linux/arch/i386/kernel/entry.S
@@ -908,5 +908,6 @@ ENTRY(sys_call_table)
 	.long sys_utimes
  	.long sys_fadvise64_64
 	.long sys_ni_syscall	/* sys_vserver */
+	.long sys_sched_get_affinity_span
 
 syscall_table_size=(.-sys_call_table)
--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -2793,6 +2793,17 @@ out_unlock:
 }
 
 /**
+ * sys_sched_affinity_span - get the cpu affinity mask size possible
+ *
+ * returns the size of cpumask_t. Note that this is a hard upper limit
+ * for the # of CPUs.
+ */
+asmlinkage long sys_sched_get_affinity_span(void)
+{
+	return sizeof(cpumask_t);
+}
+
+/**
  * sys_sched_yield - yield the current processor to other threads.
  *
  * this function yields the current CPU by moving the calling thread

  parent reply	other threads:[~2004-03-18 11:28 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 [this message]
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
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=20040318112913.GA13981@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@osdl.org \
    --cc=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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