On 5/1/07, Theodore Tso <[EMAIL PROTECTED]> wrote:
There are two ways of implementing this. One is to have the
JVM periodically poll using a pthread_getrusage() interface.
Not a good idea.
A better
choice might be some kind of per-thread CPU limit, that would result
in a
On 5/1/07, Bill Irwin <[EMAIL PROTECTED]> wrote:
The basic
idea is to try to do it similarly to how everyone else does so userspace
(I suppose this would include glibc) don't have to bend over backward to
accommodate it. Or basically to do what everyone expects.
I think beside RUSAGE_THREAD
On 5/1/07, Bill Irwin <[EMAIL PROTECTED]> wrote:
A sort of note for me to refer back to when I get the rest of the way
here. AIX does this with getrusage(RUSAGE_THREAD,...), Solaris with
getrusage(RUSAGE_LWP,...),
RUSAGE_LWP is a remnant of Solaris' M-on-N thread library days. No
reason to
On 5/1/07, Bill Irwin [EMAIL PROTECTED] wrote:
A sort of note for me to refer back to when I get the rest of the way
here. AIX does this with getrusage(RUSAGE_THREAD,...), Solaris with
getrusage(RUSAGE_LWP,...),
RUSAGE_LWP is a remnant of Solaris' M-on-N thread library days. No
reason to got
On 5/1/07, Bill Irwin [EMAIL PROTECTED] wrote:
The basic
idea is to try to do it similarly to how everyone else does so userspace
(I suppose this would include glibc) don't have to bend over backward to
accommodate it. Or basically to do what everyone expects.
I think beside RUSAGE_THREAD
On 5/1/07, Theodore Tso [EMAIL PROTECTED] wrote:
There are two ways of implementing this. One is to have the
JVM periodically poll using a pthread_getrusage() interface.
Not a good idea.
A better
choice might be some kind of per-thread CPU limit, that would result
in a
On 5/1/07, Theodore Tso [EMAIL PROTECTED] wrote:
The question is should we use setrlimit() to set the per-thread CPU
limit, given that we would need some separate interface to set signal
that should be sent.
Is there any reason why we should have the interface specify whether
the signal should
On 4/30/07, Rik van Riel <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
> Because right now, I don't know where we are with respect to these things and
> I doubt if many of our users know either. How can Michael write a manpage for
> this is we don't tell him what it all does?
I think we've
On 4/30/07, Rik van Riel [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Because right now, I don't know where we are with respect to these things and
I doubt if many of our users know either. How can Michael write a manpage for
this is we don't tell him what it all does?
I think we've been
H. Peter Anvin wrote:
> The main use of atime seems to be to figure out when something can be
> automatically deleted. Anyone else have other usage scenarios?
It's not atime which cannot be set, it's ctime.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain Vi
onally the sys_utime function was changed to match
compat_sys_utime which already use do_utimes instead of duplicating the
work.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
Alexey Dobriyan wrote:
> It should be tiny little bit nicer to call them "ts[2]" because they're
> timeSpecs.
I always use tv since the prefix of the element names hasn't been
changed. ts.tv_sec vs tv.tv_sec. The latter looks nicer.
--
➧ Ulrich Drepper ➧ Red Hat, Inc.
This is the updated test program for the utimensat syscall. Cleaned up
a bit and extended to cover the lutimesat functionality.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
#include
#include
#include
#include
#include
#include
#define __NR_utimensat 280
test program separately.
Signed-off-by: Ulrich Drepper <[EMAIL PROTECTED]>
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index be133f1..b4cf563 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -955,15 +955,25 @@ osf_setitimer(int which,
tch somewhere? I'll make the change and
merge it with the utimensat patch.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
somewhere? I'll make the change and
merge it with the utimensat patch.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
test program separately.
Signed-off-by: Ulrich Drepper [EMAIL PROTECTED]
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index be133f1..b4cf563 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -955,15 +955,25 @@ osf_setitimer(int which, struct
This is the updated test program for the utimensat syscall. Cleaned up
a bit and extended to cover the lutimesat functionality.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
#include errno.h
#include fcntl.h
#include time.h
#include sys/time.h
#include stddef.h
Alexey Dobriyan wrote:
It should be tiny little bit nicer to call them ts[2] because they're
timeSpecs.
I always use tv since the prefix of the element names hasn't been
changed. ts.tv_sec vs tv.tv_sec. The latter looks nicer.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain
the sys_utime function was changed to match
compat_sys_utime which already use do_utimes instead of duplicating the
work.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
H. Peter Anvin wrote:
The main use of atime seems to be to figure out when something can be
automatically deleted. Anyone else have other usage scenarios?
It's not atime which cannot be set, it's ctime.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA
One comment I got suggested to clean up the overflow tests. There
is no reason to not perform the full micro-second overflow test
in those two places. The four conditions are reduced by the compiler
to just two tests so there's no problems with performance.
Signed-off-by: Ulrich Drepper <[EM
Neil Brown wrote:
> Does it also specify how to find out what granularity is used by the
> filesystem? I had a need for this just recently and couldn't see any
> way to extract it.
That's still on the table. We might end up with an fpathconf() solution.
--
➧ Ulrich Drepper ➧ Red
H. Peter Anvin wrote:
> Primarily to let a backup program restore the full state of the filesystem.
Is this wanted? Or needed? I would think there are good reasons why
this hasn't been done so far. Intrusion detection is one reason I can
think of.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧
Oops, little bug, I hooked-up the wrong syscall for the IA32 compat
code. Fixed in this revision.
Signed-off-by: Ulrich Drepper <[EMAIL PROTECTED]>
diff --git a/arch/x86_64/ia32/ia32entry.S b/arch/x86_64/ia32/ia32entry.S
index 796df69..12611c8 100644
--- a/arch/x86_64/ia32/ia32entry.S
orking group and thought it's a toss up.
> Something else... if we're dickering with these interfaces, shouldn't we
> allow setting atime as well?
Why? To allow somebody to hide her/his tracks?
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
> Do you have a testcase app which can be used by arch maintainers?
Attached here.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
#include
#include
#include
#include
#include
#include
#define UTIME_NOW ((1l << 30) - 1l)
#define UTIME_OMIT
parameters. In fact, I think one problem where the
old code wouldn't recognize certain overflows (if tv_nsec * 1000 overflows).
I've tested the code on x86-64.
Signed-off-by: Ulrich Drepper <[EMAIL PROTECTED]>
diff --git a/arch/x86_64/ia32/ia32entry.S b/arch/x86_64/ia32/ia32entry.S
index 7
parameters. In fact, I think one problem where the
old code wouldn't recognize certain overflows (if tv_nsec * 1000 overflows).
I've tested the code on x86-64.
Signed-off-by: Ulrich Drepper [EMAIL PROTECTED]
diff --git a/arch/x86_64/ia32/ia32entry.S b/arch/x86_64/ia32/ia32entry.S
index 796df69
can be used by arch maintainers?
Attached here.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
#include errno.h
#include fcntl.h
#include time.h
#include sys/time.h
#include stddef.h
#include syscall.h
#define UTIME_NOW ((1l 30) - 1l)
#define UTIME_OMIT ((1l
group and thought it's a toss up.
Something else... if we're dickering with these interfaces, shouldn't we
allow setting atime as well?
Why? To allow somebody to hide her/his tracks?
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP
Oops, little bug, I hooked-up the wrong syscall for the IA32 compat
code. Fixed in this revision.
Signed-off-by: Ulrich Drepper [EMAIL PROTECTED]
diff --git a/arch/x86_64/ia32/ia32entry.S b/arch/x86_64/ia32/ia32entry.S
index 796df69..12611c8 100644
--- a/arch/x86_64/ia32/ia32entry.S
+++ b/arch
H. Peter Anvin wrote:
Primarily to let a backup program restore the full state of the filesystem.
Is this wanted? Or needed? I would think there are good reasons why
this hasn't been done so far. Intrusion detection is one reason I can
think of.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444
Neil Brown wrote:
Does it also specify how to find out what granularity is used by the
filesystem? I had a need for this just recently and couldn't see any
way to extract it.
That's still on the table. We might end up with an fpathconf() solution.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444
One comment I got suggested to clean up the overflow tests. There
is no reason to not perform the full micro-second overflow test
in those two places. The four conditions are reduced by the compiler
to just two tests so there's no problems with performance.
Signed-off-by: Ulrich Drepper [EMAIL
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
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
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/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/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
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)
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:
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/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/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, 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
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,
the PID is -1 so we dont actually know which task we are waiting for.
That's a special case. Most programs don't
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, 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/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/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.
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
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:
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/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
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, 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.
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/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
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.
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
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, 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
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
ke me change the libc 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 D
or the whole 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]
. Use them only if
you know what you do.
By default madvise(MADV_DONTNEED) is used. With the environment variable
MALLOC_MADVISE
one can select a different hint. The value of the envvar must be the
number of that other hint.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain
the details.
Nothing came out of this but if this is possible it would be yet another
way to avoid mmap_sem locking, right?
--
➧ 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
.
Nothing came out of this but if this is possible it would be yet another
way to avoid mmap_sem locking, right?
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
. Use them only if
you know what you do.
By default madvise(MADV_DONTNEED) is used. With the environment variable
MALLOC_MADVISE
one can select a different hint. The value of the envvar must be the
number of that other hint.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain
On 3/15/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
But fact is POSIX defined PRIVATE and SHARED, allowing clear separation, and
optimal performance if carefuly implemented. Time has come for linux to have
better threading performance.
Now that I've been pointed to the thread I can comment on
Eric Dumazet wrote:
> You were CC on this one, you can find an archive here :
You cc:ed my gmail account. I don't pick out mails sent to me there.
If you want me to look at something you have to send it to my
@redhat.com address.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mount
Nick Piggin wrote:
> Sad. Although Ulrich did seem interested at one point I think? Ulrich,
> do you agree at least with the interface that Eric is proposing?
I have no idea what you're talking about.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signatu
Nick Piggin wrote:
Sad. Although Ulrich did seem interested at one point I think? Ulrich,
do you agree at least with the interface that Eric is proposing?
I have no idea what you're talking about.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Eric Dumazet wrote:
You were CC on this one, you can find an archive here :
You cc:ed my gmail account. I don't pick out mails sent to me there.
If you want me to look at something you have to send it to my
@redhat.com address.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain
On 3/15/07, Eric Dumazet [EMAIL PROTECTED] wrote:
But fact is POSIX defined PRIVATE and SHARED, allowing clear separation, and
optimal performance if carefuly implemented. Time has come for linux to have
better threading performance.
Now that I've been pointed to the thread I can comment on
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
mory regions which contain only administrative data
and where every page is used right away. Substituting N page faults for
one madvise call probably is a win.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
to determine the number of worker threads.
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
remove 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 ❖
signatu
l the NUMA topology
>> framework can provide something better. Even without a popcnt
>> instruction in the CPU (64-bit albeit) it's twice as fast as the the
>> stat() method proposed.
>
> I'm surprised - I'd have expected sched_getaffinity() to be vastly quicker
> that do
faults. It quickly adds up.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
ne only once 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
t real problems from being addressed.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
when these pages are released.
Sounds good to me.
> This would all halve the maximum amount of swap which 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
401 - 500 of 743 matches
Mail list logo
