Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the F
d a signal explicitly to this thread
(to implement pthread_kill). The PID of this initial thread is now
used as the PID of the thread group.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 U
s exercise.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
irst clone() but this is solvable.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscri
.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-k
on this?
"Fixing" alone won't cut it. I've started a rewrite and send Linus
more comments about what is needed but not even got a reply. Seems
the short interest span is already over.
--
---. ,-. 1325 Chesapeake Terrace
Ulri
Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please re
and find somebody who is working on glibc
to back up this "statement" and not some idiot like you who has no
inside whatsoever. If you cannot find anybody I demand a public
apology from you.
--
---. ,-. 1325 Chesapeake Terrace
Ulri
. Introducing breakage just to possibily
avoid them in future is stupid.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com
it),
It will need a new libc version anyway.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list
.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
modifications necessary. This is
the end of the story as far as I'm concerned.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the F
ot execute libc.so.5. This only works with
glibc.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this
there).
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
P
hat directory (/usr/i486-linux-libc5/lib).
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
Symlinks can be missing or can be wrong.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the lin
every CPU.
CPU0 CPU1
0: 146727 153389IO-APIC-edge timer
[...]
NMI: 300035 300035
LOC: 300028 300028
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 U
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the F
l" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' d
t seems OK. Thanks,
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscri
with the common case without
syscalls can be applied here as well.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com
..)
close (fd)
sem_syscall (addr)
i.e., it can be mapped to a memory reference again.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com
n them ?
See above. Permissions are only allowed for named semaphores.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `-
The kernel representation of the mutex must not be disassociated from
the shared memory region.
Even if you all think very little about Solaris, look at the kernel
interface for semaphores.
--
---. ,-. 1325 Chesapeake Terrace
Ulri
the final implementation will be like. For
UP and SMP machines I definitely want to have as much as possible at
user-level. If you need a special libpthread for NUMA machines, so be
it.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper
.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
ad_mutex_unlock (m1);
pthread_mutex_lock (m2);
}
return 0;
}
~~~
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 940
Jens Axboe [EMAIL PROTECTED] writes:
Does attached patch fix it?
Yes.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com
since it's useless for
me.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line
e case
and necessary to implement the fast lazy FPU saving/restoring.
Processes which never use the FPU never initialize it.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' d
ssor first. The kernel can detect when the FPU is used for
the first time.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To u
.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
forever signal the
gcc semantics.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line
are defined as macros. You'll have to add a
configure test.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from
er problem.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
initialize.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On 4/20/07, Andreas Gruenbacher [EMAIL PROTECTED] wrote:
Yes, that one, sorry. The values it obtains that way are not reliable.
Why should the mount point info together with the filesystem type not
be reliable? You're trying to find an excuse to break tings, that
seems all there is.
-
To
On 4/20/07, Andreas Gruenbacher [EMAIL PROTECTED] wrote:
Possibly for fstatfs(): fstatfs() has no way of looking up mount points per
path name in /proc/mounts, and so it resorts to mapping from the numeric
statfs-f_type to the filesystem name (e.g., ext3), looks up the first
mount point with
On 4/20/07, Andreas Gruenbacher [EMAIL PROTECTED] wrote:
The code also seems to stop at the first matching mount point. You can have
the same device mounted on the same mount point multiple times but with
different mount options, e.g., [...]
You can unfortunately do many stupid things. That's
On 4/20/07, Andrew Morton [EMAIL PROTECTED] wrote:
OK, we need to flesh this out a lot please. People often get confused
about what our MADV_DONTNEED behaviour is.
Well, there's not really much to flesh out. The current MADV_DONTNEED
is useful in some situations. The behavior cannot be
On 4/21/07, Hugh Dickins [EMAIL PROTECTED] wrote:
But the Linux MADV_DONTNEED does throw away
data from a PROT_WRITE,MAP_PRIVATE mapping (or brk or stack) - those
changes are discarded, and a subsequent access will revert to zeroes
or the underlying mapped file. Been like that since before
On 4/21/07, Ingo Molnar [EMAIL PROTECTED] wrote:
on a simple 'ls' command:
21310 clone(child_stack=0, ...) = 21399
...
21399 execve(/bin/ls,
...
21310 waitpid(-1, unfinished ...
the PID is -1 so we dont actually know which task we are waiting for.
That's a special case. Most
On 4/21/07, Andreas Gruenbacher [EMAIL PROTECTED] wrote:
What I described is a supported feature, nothing more and nothing less. It's
also relatively easy to handle this case correctly in glibc, e.g., [...]
This is only useful if the requirement of an ordered /proc/mounts is
part of the kernel
On 4/21/07, Kyle Moffett [EMAIL PROTECTED] wrote:
It might be nice if it was possible to actively contribute your CPU
time to a child process. For example:
int sched_donate(pid_t pid, struct timeval *time, int percentage);
If you do this, and it has been requested many a times, then please
On 4/21/07, Linus Torvalds [EMAIL PROTECTED] wrote:
And how the hell do you imagine you'd even *know* what thread holds the
futex?
We know this in most cases. This is information recorded, for
instance, in the mutex data structure. You might have missed my the
interface must be extended
On 4/22/07, William Lee Irwin III [EMAIL PROTECTED] wrote:
I'm just looking for what people want the API to be here. With that in
hand we can just go out and do whatever needs to be done.
I think a sched_yield_to is one interface:
int sched_yield_to(pid_t);
For futex(), the extension is
On 4/22/07, William Lee Irwin III [EMAIL PROTECTED] wrote:
On Sun, Apr 22, 2007 at 12:17:31AM -0700, Ulrich Drepper wrote:
For futex(), the extension is needed for the FUTEX_WAIT operation. We
need a new operation FUTEX_WAIT_FOR or so which takes another (the
fourth) parameter which
On 4/22/07, Christoph Hellwig [EMAIL PROTECTED] wrote:
Why isn't MADV_FREE defined to 5 for linux? It's our first free madv
value? Also the behaviour should better match the one in solaris or BSD,
the last thing we need is slightly different behaviour from operating
systems supporting this for
On 4/23/07, Pierre Peiffer [EMAIL PROTECTED] wrote:
Following this mail sent few weeks ago, here is a patch which should meet your
requirements. [...]
It looks mostly good. I wouldn't use the high bit to differentiate
the 64-bit operations, though. Since we do not allow to apply it to
all
On 4/24/07, Pierre Peiffer [EMAIL PROTECTED] wrote:
Something like that may be...
Yep, looks goot to me.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Andrew Morton wrote:
Why do we want 64-bit futexes?
I sent this to you already on 1/12/2007:
http://udrepper.livejournal.com/13123.html
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
have to use internal locks, modify the
state information, and then release it. This is terribly inefficient
when many threads are used. With 64bit futexes the state information
can be kept in the futex object and we don't need an internal lock,
hence the speed-up.
--
➧ Ulrich Drepper ➧ Red Hat
On 3/15/07, Hugh Dickins [EMAIL PROTECTED] wrote:
I'm guessing that the pthread stacks are mmap'ed as greatest extents
(probably because that's the easiest way to keep them apart), rather
than as small MAP_GROWSDOWN areas to be expanded later on fault.
Please all, forget about MAP_GROWSDOWN.
On 3/15/07, Nick Piggin [EMAIL PROTECTED] wrote:
There should be little contention on the memory in the global hash anyway,
because we can roughly reduce contention as a factor of
hash-size/cacheline-size.
What we will have are cache misses on the global table... but we're going to
get cache
On 3/7/07, Davide Libenzi davidel@xmailserver.org wrote:
Let's do this. How about you throw this way one of the case that would
possibly break, and I test it?
Since you make such claims I assume your signalfd() implementation
considers a signal delivered once it is reported to an epoll()
Evgeniy Polyakov wrote:
I think that mean that everybody is happy with APi, design and set of
features.
No comment means that I still have not been able to test anything since
regardless of what version I tried, it failed to build.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St
for files the same applies in some
situations, e.g., for network filesystems.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
discount it. Yes, the interface
is not the best. But this is what you get if you cannot dictate
interfaces to everybody. You have to make concessions.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
code but the concept is very sound and
definitely along the way the specification allows it:
Acked-by: Ulrich Drepper [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
code. The reason is that there is a big drawback.
So far, when we allocate a new arena, we allocate address space with
PROT_NONE and only when we need memory the protection is changed to
PROT_READ|PROT_WRITE. This is the advantage of catching wild pointer
accesses.
--
➧ Ulrich Drepper ➧ Red Hat
On 4/7/07, Eric Dumazet [EMAIL PROTECTED] wrote:
I am not sure what you want to say.
What Jakub meant is that it is OK for the kernel to reject using
unaligned 64-bit futexes. Just return an error in all cases (not just
in some).
-
To unsubscribe from this list: send the line unsubscribe
In their closed chambers (well, workshops,
http://lwn.net/Articles/226351/), the filesystem developers complain
about readdir. I fully appreciate the difficulties. But what I fail
to see so far is any proposal for an alternative interface.
The phase to get new functionality included in the
On 4/7/07, Christoph Hellwig [EMAIL PROTECTED] wrote:
It's not going to solve anything at all. We can't stop supporting
functionality that has been there forever.
Not necessarily.
One problem here is that the interface for using readdir() with and
without telldir()/seekdir() is the same. A
On 4/8/07, Theodore Tso [EMAIL PROTECTED] wrote:
Ulrich, is it too late to insert a clarification that the telldir()
cookie isn't guaranteed to be valid after closedir() *or* rewinddir()?
It's never too late.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On 4/8/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
More fundamentally, the telldir cookie should never be valid when
applied to a different DIR * (even one that refers to the same directory.)
Don't worry about this. This is clearly the semantics which was
always wanted. I've filed a defect
On 4/10/07, Theodore Tso [EMAIL PROTECTED] wrote:
That might work. But if in the long term we want to separate out what
we can send back via telldir/seekdir, and some future new Posix
interface, [...]
With all these discussions about fixes for telldir, do we want to
persue an alternative
On 4/10/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
It rather makes any user space accesses irrelevant. The main question
seems to be if we can realistically increase the cookie size even to 64
bits.
On 32-bit platforms, *not* using _FILE_OFFSET_BITS=64 is already today
a stupid thing to do.
but this means either waiting or creating several/many threads.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
in
glibc in case the syscall does not exist at all.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
On 3/2/07, Dave Kleikamp [EMAIL PROTECTED] wrote:
Then there's no need for sys_allocate to return a long.
Every syscall must return a long. Otherwise you can have problems on
64-bit archs.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
a mmap(MAP_SHARED) page has
been written to.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
. Add to then the block granularity (we use f_bsize as
returned from fstatfs but that's not the best value in some cases) and
you have compelling data to have generic code in the kernel. Then libc
implementation can then go away completely which is a good thing.
--
➧ Ulrich Drepper ➧ Red Hat, Inc
this unless
compression is turned off.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
already been written posix_fallocate cannot change it.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
implementation of memory
mapped files. You don't use MAP_SHARED on such filesystems, it'll eat
your kittens sooner or later anyway.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
at runtime) then the code is dropped. E.g., the
current Fedora glibc does not support 2.6.8 or earlier.
So, don't let the compat code be a factor in the decision making.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital
.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
On 3/7/07, Linus Torvalds [EMAIL PROTECTED] wrote:
1) You want standard delivery only:
- Just dont use signalfd
2) you want signalfd only:
- Do a sigprocmask(SIG_BLOCK) of the same mask you pass to signalfd
If you want both, you can have it. Race free.
.. but maybe with more code
kernel code.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
in the real solution the gap between those two and the simple
stat() call is even bigger.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
likely it won't be. So, the dontneed-list should be a simple
FIFO.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
to rip out hotpluging. I'm
certainly in favor of that, it creates huge problems for no real
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.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444
.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
would (and is not) cached, it's
re-read every time. We might add very limited caching (for a few
seconds) but that's as much as we can go.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
the limited sys_nr_cpus although
ideally then we'd have two syscalls (probed CPUs, active CPUs, in which
case sys_sysconf is the better choice).
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
that determining the CPU count is
terribly expensive and there is a simple proposal to make it faster by
keeping /sys/devices/system/cpu/ free from anything but cpu* directories.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
in the distant future NUMA topology information is
easily and speedily accessible.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
other way.
Well, who's brace enough to submit sys_sysconf() again?
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
of magnitude better than the best solution
available today. This is my main concern right now.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
be retrieved every time
(with perhaps minimal caching of a few secs, but this requires
gettimeofday calls...). All of a sudden this is not micro benchmark
anymore. It's a real issue which we only became aware of because it is
noticeable in real life.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444
/system/cpu/cpu3/online
This is a quad core machine and cpu0 doesn't have the 'online' file
(2.6.19 kernel). So, if nobody noticed this it's not needed and we can
just remove CPUs from /sys/devices/system/cpu when they are brought
offline, right?
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St
can be used. iirc
i386 supports 27 bits of swapcache indexing, and 26 bits is 274GB, which
is hopefully enough..
Boo hoo, poor 32-bit machines. People with demands of 274G should get
a real machine instead.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA
problems from being addressed.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
for the madvise call and not twice as of
today with mmap and mprotect both needing the semaphore. This can
reduce the contention quite a bit.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
. It quickly adds up.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
proposed.
I'm surprised - I'd have expected sched_getaffinity() to be vastly quicker
that doing fileystem operations.
You mean because it's only a factor of two? Well, it's not once you
count the whole overhead.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA
the
mapping for the pages and therefore upon new access it will provide
empty pages.
We want the pages to be kept around, even mapped, and only if memory
pressure is high enough collected and unmapped.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
.
For sysconf() we still need better support. Maybe now somebody will
step up and say they need faster sysconf as well.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
1 - 100 of 743 matches
Mail list logo
