On Wed, Apr 04, 2007 at 02:47:32AM -0400, Jakub Jelinek wrote:
> On Tue, Apr 03, 2007 at 07:04:58PM -0700, Paul Jackson wrote:
> > There are really at least four "number of CPUs" answers here, and we
> > should be aware of which we are providing. There are, in order of
> > decreasing size:
> > 1
* Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> On 04/04, Ingo Molnar wrote:
> >
> > * Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> >
> > > But we don't need tasklist_lock at all, we can use
> > > rcu_read_lock/unlock. Q: don't we need task_rq_lock() to read
> > > ->cpus_allowed "atomically" ?
> >
On 04/04, Ingo Molnar wrote:
>
> * Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > But we don't need tasklist_lock at all, we can use
> > rcu_read_lock/unlock. Q: don't we need task_rq_lock() to read
> > ->cpus_allowed "atomically" ?
>
> right now ->cpus_allowed is protected by tasklist_lock. W
* Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> But we don't need tasklist_lock at all, we can use
> rcu_read_lock/unlock. Q: don't we need task_rq_lock() to read
> ->cpus_allowed "atomically" ?
right now ->cpus_allowed is protected by tasklist_lock. We cannot do RCU
here because ->cpus_allowed
On 04/03, Andrew Morton wrote:
>
> On Tue, 03 Apr 2007 16:00:50 -0700
> Ulrich Drepper <[EMAIL PROTECTED]> wrote:
>
> > If there is possibility to treat this case special and make it faster,
> > please do so. It would be best to allow pid==0 as a special case so
> > that callers don't have to fin
Jakub wrote:
> OpenMP wants (4) and I'll change it that way.
Good. Are you referring to a change in glibc or in OpenMP?
> sysconf(_SC_NPROCESSORS_ONLN) must return (3) (this currently scans
> /proc/stat)
Ok
> sysconf(_SC_NPROCESSORS_CONF) should IMHO return (2) (this currently
> scans /proc/c
On Tue, Apr 03, 2007 at 07:04:58PM -0700, Paul Jackson wrote:
> Andrew wrote:
> > I'd have thought that in general an application should be querying its
> > present affinity mask - something like sched_getaffinity()? That fixes the
> > CPU hotplug issues too, of course.
>
> The sched_getaffinity
H. Peter Anvin a écrit :
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Mutable data should be separated from code. I think any current CPU
will do fine as long as they are in separate 128-byte chunks, but they
need at least that much separation.
P4 manual says that if one processor modifie
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Mutable data should be separated from code. I think any current CPU
will do fine as long as they are in separate 128-byte chunks, but they
need at least that much separation.
P4 manual says that if one processor modifies data within 2k of anothe
H. Peter Anvin a écrit :
Eric Dumazet wrote:
There is one thing that always worried me.
Intel & AMD manuals make clear that mixing data and program in the
same page is bad for performance.
In particular, x86_64 vsyscall put jiffies and other
vsyscall_gtod_data_t right in the midle of code.
H. Peter Anvin wrote:
> Mutable data should be separated from code. I think any current CPU
> will do fine as long as they are in separate 128-byte chunks, but they
> need at least that much separation.
P4 manual says that if one processor modifies data within 2k of another
processor executing cod
Eric Dumazet wrote:
There is one thing that always worried me.
Intel & AMD manuals make clear that mixing data and program in the same
page is bad for performance.
In particular, x86_64 vsyscall put jiffies and other
vsyscall_gtod_data_t right in the midle of code. That is certainly not
wi
H. Peter Anvin a écrit :
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Sounds like it would need a device which can be waited upon for changes.
A vdso-like shared page could have a futex in it.
Yes, but a futex couldn't be waited upon with a bunch of other things as
part of a poll or a
Ulrich wrote:
> For sysconf() we still need better support. Maybe now somebody will
> step up and say they need faster sysconf as well.
That won't be me ;).
For any kernel compiled with CONFIG_CPUSETS (which includes the major
distros I am aware of), one can just count the bits in the top cpuset
Ulrich wrote:
> But all this of course does not solve the issue sysconf() has. In
> sysconf we cannot use sched_getaffinity since all the systems CPUs must
> be reported.
Good point. Yes, sysconf(_SC_NPROCESSORS_CONF) really needs to continue
returning the number of CPUs online, to maintain comp
Andrew wrote:
> > But all this of course does not solve the issue sysconf() has. In
> > sysconf we cannot use sched_getaffinity since all the systems CPUs must
> > be reported.
>
> OK.
>
> This is excecptionally gruesome, but one could run sched_getaffinity()
> against pid 1 (init). Which will
Andrew wrote:
> Paul, could you please describe what cpusets' policy is in the presence of
> CPU additional and removal?
Currently, if we remove the last CPU in a cpuset, we give that cpuset
the CPUs of its parent cpuset, in order to ensure that every cpuset
with tasks attached actually has some C
Andrew wrote:
> I'd have thought that in general an application should be querying its
> present affinity mask - something like sched_getaffinity()? That fixes the
> CPU hotplug issues too, of course.
The sched_getaffinity call is quick, too, and it nicely reflects any
cpuset constraints, while s
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Sounds like it would need a device which can be waited upon for changes.
A vdso-like shared page could have a futex in it.
Yes, but a futex couldn't be waited upon with a bunch of other things as
part of a poll or a select. The cost of readi
H. Peter Anvin wrote:
> Sounds like it would need a device which can be waited upon for changes.
A vdso-like shared page could have a futex in it.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Ulrich Drepper wrote:
Davide Libenzi wrote:
It sucks when seen from a micro-bench POV, but does it really matter
overall? The vast majority of software usually calls
sysconf(_SC_NPROCESSORS_*) with very little frequency (mostly once at
initialization time) anyway. That's what 50us / call?
Th
Andrew Morton wrote:
> Does anyone see a reason why we cannot do this?
Shouldn't sched_setaffinity get the same treatment for symmetry reasons?
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
On Tue, 3 Apr 2007 22:13:07 +0200, Ingo Oeser <[EMAIL PROTECTED]> wrote:
> Hi Ulrich,
>
> On Tuesday 03 April 2007, Ulrich Drepper wrote:
> > So, anybody else has a proposal? This is a pressing issue and cannot
> > wait until someday in the distant future NUMA topology information is
> > easily
On Tue, 03 Apr 2007 16:00:50 -0700
Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > Now it could be argued that the current behaviour is that sane thing: we
> > allow the process to "pin" itself to not-present CPUs and just handle it in
> > the CPU scheduler.
>
> As a stop-gap
Andrew Morton wrote:
> Now it could be argued that the current behaviour is that sane thing: we
> allow the process to "pin" itself to not-present CPUs and just handle it in
> the CPU scheduler.
As a stop-gap solution Jakub will likely implement the sched_getaffinity
hack. So, it would realy be b
On Tue, 03 Apr 2007 15:13:09 -0700
Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > Did we mean to go off-list?
>
> Oops, no, pressed the wrong button.
>
> >> Andrew Morton wrote:
> >>> So I'd have thought that in general an application should be querying its
> >>> present af
Andrew Morton wrote:
> Did we mean to go off-list?
Oops, no, pressed the wrong button.
>> Andrew Morton wrote:
>>> So I'd have thought that in general an application should be querying its
>>> present affinity mask - something like sched_getaffinity()? That fixes the
>>> CPU hotplug issues too,
Ulrich Drepper a écrit :
Siddha, Suresh B wrote:
No. Logical cpu hotplug uses these interfaces to make a cpu go offline
and online.
You missed my sarcasms, email is bad for conveying it. The point is
nobody really cares about that hotplug nonsense to have noticed the bug.
And still does this
Andi Kleen wrote:
> Migration is fundamentally incompatible with many CPU optimizations.
> But that's not a reason to not optimize anymore.
>
I've been thinking about ways in which Xen could provide the current
vcpu->cpu map to guest domains. Obviously this would change over time,
but it could
Ulrich Drepper wrote:
> Siddha, Suresh B wrote:a
> > Not all of the cpu* directories in /sys/devices/system/cpu may be
> > online.
>
> Apparently this information isn't needed. It's very easy to verify:
>
> $ ls /sys/devices/system/cpu/*/online
> /sys/devices/system/cpu/cpu1/online /sys/devices
Siddha, Suresh B wrote:
> No. Logical cpu hotplug uses these interfaces to make a cpu go offline
> and online.
You missed my sarcasms, email is bad for conveying it. The point is
nobody really cares about that hotplug nonsense to have noticed the bug.
And still does this nonsense prevent real pr
On Tue, 03 Apr 2007 09:54:46 -0700
Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> More and more code depends on knowing the number of processors in the
> system to efficiently scale the code. E.g., in OpenMP it is used by
> default to determine how many threads to create. Creating more threads
> th
On Tue, Apr 03, 2007 at 12:55:22PM -0700, Ulrich Drepper wrote:
> Siddha, Suresh B wrote:a
> > Not all of the cpu* directories in /sys/devices/system/cpu may be
> > online.
>
> Apparently this information isn't needed. It's very easy to verify:
>
> $ ls /sys/devices/system/cpu/*/online
> /sys/de
Hi Ulrich,
On Tuesday 03 April 2007, Ulrich Drepper wrote:
> So, anybody else has a proposal? This is a pressing issue and cannot
> wait until someday in the distant future NUMA topology information is
> easily and speedily accessible.
Since for now you just need a fast and dirty hack, which wil
Siddha, Suresh B wrote:a
> Not all of the cpu* directories in /sys/devices/system/cpu may be
> online.
Apparently this information isn't needed. It's very easy to verify:
$ ls /sys/devices/system/cpu/*/online
/sys/devices/system/cpu/cpu1/online /sys/devices/system/cpu/cpu2/online
/sys/devices/
On Tue, Apr 03, 2007 at 10:59:53AM -0700, Ulrich Drepper wrote:
> Siddha, Suresh B wrote:
> > Not all of the cpu* directories in /sys/devices/system/cpu may be
> > online.
>
> Brilliant. You people really know how to create user interfaces. So
> now in any case per CPU another stat/access syscal
Davide Libenzi wrote:
> It sucks when seen from a micro-bench POV, but does it really matter
> overall? The vast majority of software usually calls
> sysconf(_SC_NPROCESSORS_*) with very little frequency (mostly once at
> initialization time) anyway. That's what 50us / call?
This is not today's
On Tue, 3 Apr 2007, Ulrich Drepper wrote:
> More and more code depends on knowing the number of processors in the
> system to efficiently scale the code. E.g., in OpenMP it is used by
> default to determine how many threads to create. Creating more threads
> than there are processors/cores doesn
* Ulrich Drepper ([EMAIL PROTECTED]) wrote:
> glibc for a long time provides functionality to retrieve the number
> through sysconf() and this is what fortunately most programs use. The
> problem is that we are currently using /proc/cpuinfo since this is all
> there was available at that time. C
Andi Kleen wrote:
> I would be opposed for adding another page per process at least
> because the per process memory footprint in Linux is imho already
> too large.
That's a single page shared by all threads on the system. Or make this
a page per NUMA node. And if the number of threads is larger
On Tue, Apr 03, 2007 at 11:05:49AM -0700, Ulrich Drepper wrote:
> Andi Kleen wrote:
> >> There is an inexpensive solution: finally make the vdso concept a bit
> >> more flexible. You could add a vdso call to get the processor count.
> >> The vdso code itself can use a data page mapped in from the
Andi Kleen wrote:
>> There is an inexpensive solution: finally make the vdso concept a bit
>> more flexible. You could add a vdso call to get the processor count.
>> The vdso code itself can use a data page mapped in from the kernel.
>
> The ELF aux vector is exactly that already.
No. The aux v
Siddha, Suresh B wrote:
> Not all of the cpu* directories in /sys/devices/system/cpu may be
> online.
Brilliant. You people really know how to create user interfaces. So
now in any case per CPU another stat/access syscall is needed to check
the 'online' pseudo-file? With this the readdir soluti
On Tue, Apr 03, 2007 at 10:45:35AM -0700, Ulrich Drepper wrote:
> Andi Kleen wrote:
> >>> Topology is dependent on the number of CPUs.
> >> Not all of it.
> >
> > What is not?
>
> Memory banks can exist without a CPU present. The places where you can
> plug in memory don't change and so the memo
Andi Kleen wrote:
>>> Topology is dependent on the number of CPUs.
>> Not all of it.
>
> What is not?
Memory banks can exist without a CPU present. The places where you can
plug in memory don't change and so the memory hierarchy can be described.
> Hmm, e.g. in OpenMP you would have another th
On Tue, Apr 03, 2007 at 10:30:47AM -0700, Ulrich Drepper wrote:
> Reading /proc/cpuinfo or /sys/devices/system/cpu reflects the
> current CPU count.
Not all of the cpu* directories in /sys/devices/system/cpu may be
online.
thanks,
suresh
-
To unsubscribe from this list: send the line "unsubscri
linux-os (Dick Johnson) wrote:
> Shouldn't it just be another system call? 223 is currently unused. You
> could fill that up with __NR_nr_cpus. The value already exists in
> the kernel.
You forget about Linus' credo "there shall be no sysconf-like syscall".
I'd be all for sys_sysconf or even the
Andi Kleen wrote:
> Topology is dependent on the number of CPUs.
Not all of it.
> Hot plugging is a completely orthogonal problem. Even your original
> proposal wouldn't address it.
Nonsense. Reading /proc/cpuinfo or /sys/devices/system/cpu reflects the
current CPU count. The information read
On Tue, Apr 03, 2007 at 10:30:47AM -0700, Ulrich Drepper wrote:
> Andi Kleen wrote:
> > Topology is dependent on the number of CPUs.
>
> Not all of it.
What is not?
> We might add very limited caching (for a few
> seconds) but that's as much as we can go.
Hmm, e.g. in OpenMP you would have ano
On Tue, 3 Apr 2007, Ulrich Drepper wrote:
> More and more code depends on knowing the number of processors in the
> system to efficiently scale the code. E.g., in OpenMP it is used by
> default to determine how many threads to create. Creating more threads
> than there are processors/cores does
On Tue, Apr 03, 2007 at 06:22:41PM +0100, Alan Cox wrote:
> > benefit for the common use cases. But as it is, the number of
> > processors is not necessarily constant over the lifetime of a process.
> > The machine architecture is.
>
> Not once you have migration capable virtualisation it isnt.
On Tue, Apr 03, 2007 at 10:17:15AM -0700, Ulrich Drepper wrote:
> Andi Kleen wrote:
> > There was a proposal some time ago to put that into the ELF aux vector
> > Unfortunately there was disagreement on what information to put
> > there exactly (full topology, only limited numbers etc.)
>
> Topo
> benefit for the common use cases. But as it is, the number of
> processors is not necessarily constant over the lifetime of a process.
> The machine architecture is.
Not once you have migration capable virtualisation it isnt.
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
Andi Kleen wrote:
> There was a proposal some time ago to put that into the ELF aux vector
> Unfortunately there was disagreement on what information to put
> there exactly (full topology, only limited numbers etc.)
Topology, yes, I'm likely in favor of it.
Processor number: no. Unless you wan
Ulrich Drepper <[EMAIL PROTECTED]> writes:
> More and more code depends on knowing the number of processors in the
> system to efficiently scale the code. E.g., in OpenMP it is used by
> default to determine how many threads to create.
There are more uses for it.
> Creating more threads
> than
More and more code depends on knowing the number of processors in the
system to efficiently scale the code. E.g., in OpenMP it is used by
default to determine how many threads to create. Creating more threads
than there are processors/cores doesn't make sense.
glibc for a long time provides func
56 matches
Mail list logo
