gt; don't see how oprofile can do that as it tracks instruction pointers only.
>
> Pekka
You could try passing the --callgraph option to opcontrol.
--
Nicholas Miell <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kerne
only.
Pekka
You could try passing the --callgraph option to opcontrol.
--
Nicholas Miell [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
C++ name mangling would be extremely useful here.
Actually, why isn't the DWARF information for the functions sufficient?
--
Nicholas Miell <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
?
--
Nicholas Miell [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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
y);
t->fn2(x, y);
}
generate instruction-for-instruction identical code.
--
Nicholas Miell <[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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
fn2(int x, int y);
int x, y;
};
void testCall(struct test *t, int x, int y)
{
t-fn1(x, y);
t-fn2(x, y);
}
generate instruction-for-instruction identical code.
--
Nicholas Miell [EMAIL
D namespaces on the
same machine via a shared file mapping is logically equivalent to
accessing the same robust futex from different machines via a shared
filesystem and there's no reason to expect either operation to work
correctly.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from
equivalent to
accessing the same robust futex from different machines via a shared
filesystem and there's no reason to expect either operation to work
correctly.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Wed, 2007-10-10 at 12:14 +0200, Ingo Molnar wrote:
> * Nicholas Miell <[EMAIL PROTECTED]> wrote:
>
> > Does CFS still generate the following sysbench graphs with 2.6.23, or
> > did that get fixed?
> >
> > http://people.freebsd.org/~kris/scaling/linux-pgsq
t fixed?
http://people.freebsd.org/~kris/scaling/linux-pgsql.png
http://people.freebsd.org/~kris/scaling/linux-mysql.png
(There's also some interesting FreeBSD vs. Linux graphs in
http://people.freebsd.org/~kris/scaling/Scalability%20Update.pdf , but
AFAIK those comparisons are more indicative of glibc m
/scaling/linux-mysql.png
(There's also some interesting FreeBSD vs. Linux graphs in
http://people.freebsd.org/~kris/scaling/Scalability%20Update.pdf , but
AFAIK those comparisons are more indicative of glibc malloc performance
than Linux performance.)
--
Nicholas Miell [EMAIL PROTECTED
On Wed, 2007-10-10 at 12:14 +0200, Ingo Molnar wrote:
* Nicholas Miell [EMAIL PROTECTED] wrote:
Does CFS still generate the following sysbench graphs with 2.6.23, or
did that get fixed?
http://people.freebsd.org/~kris/scaling/linux-pgsql.png
http://people.freebsd.org/~kris/scaling
/sys/bus/pci/drivers/serial/new_id and let
Russell King ([EMAIL PROTECTED]) know if it works (or if it
doesn't, for that matter).
--
Nicholas Miell <[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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
, for that matter).
--
Nicholas Miell [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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
want to
> send to userspace programs. It would also be useful to inform
> userspace programs when we are about to start swapping something
> out, so userspace can discard cached data instead of having to
> wait for disk IO in the future.
>
> A unix signal cannot encapsulate two diffe
field
and be delivered via a signalfd.
--
Nicholas Miell [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/majordomo-info.html
Please read the FAQ at http
IX says
WIFSIGNALED(stat_val)
Evaluates to a non-zero value if status was returned for a child
process that terminated due to the receipt of a signal that was
not caught (see ).
So there's no dilemma at all and Linux is non-conformant.
--
Nicholas Miell &
if status was returned for a child
process that terminated due to the receipt of a signal that was
not caught (see signal.h).
So there's no dilemma at all and Linux is non-conformant.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe
design it inspired rather than of inotify itself.
Come up with a filesystem where given an inode you can find every
directory that has links to that inode with very little effort, convince
everybody to switch from ext3 to this new filesystem, and then maybe
inotify could start doing recursive sub
, convince
everybody to switch from ext3 to this new filesystem, and then maybe
inotify could start doing recursive subtree watches. Otherwise, it's
just not feasible.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
t it also affects the instruction count the inline heuristics
> > use?
>
> AFAIK it counts like one operand.
>
> -Andi
GCC counts newlines and semicolons and uses that number as the likely
instruction count.
See asm_insn_count() in gcc/gcc/final.c
--
Nicholas Miell <[E
operand.
-Andi
GCC counts newlines and semicolons and uses that number as the likely
instruction count.
See asm_insn_count() in gcc/gcc/final.c
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
t.) It does not take a file descriptor for the file argument.
> > Otherwise we'd also need fopenat/funlinkat, etc. Any reasons?
>
> Ulrich having an odd taste?
Solaris compatibility.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "uns
need fopenat/funlinkat, etc. Any reasons?
Ulrich having an odd taste?
Solaris compatibility.
--
Nicholas Miell [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
S namespaces but have
equivalent security identity according to LSM. Process A reads data from
file F which is not visible in process's B's namespace. You have to
prevent process B from ever getting a page that once contained data from
file F.
3) mlock() is often used by programs like GPG to
swapped out. You need to zero all
once-mlocked pages before they get reused to prevent that page from
getting swapped to disk or application bugs from leaking the key.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
and it may even simplify the code.
>
That is what I was suggesting, but I don't understand the internals of
Linux signal delivery enough to know if it is possible without
unpleasant contortions to make it work.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: sen
delivery enough to know if it is possible without
unpleasant contortions to make it work.
--
Nicholas Miell [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/majordomo
On Fri, 2007-06-22 at 17:12 -0700, Davide Libenzi wrote:
> On Fri, 22 Jun 2007, Nicholas Miell wrote:
>
> > You could just get rid of the process/sighand/whatever reference
> > entirely and just make reads on a signalfd always dequeue signals for
> > the
t; Ah got it, signalfd_detach() in include/linux/signalfd.h from
> exit_signal plus some rcu bits in signalfd lock/unlock.
You could just get rid of the process/sighand/whatever reference
entirely and just make reads on a signalfd always dequeue signals for
the current thread.
You'd lose the abi
for
the current thread.
You'd lose the ability to pass signalfds around to other processes, but
I'm not convinced that is even useful. (But I'm sure somebody smarter
than me has a valid use case and would love to share :-)
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
On Fri, 2007-06-22 at 17:12 -0700, Davide Libenzi wrote:
On Fri, 22 Jun 2007, Nicholas Miell wrote:
You could just get rid of the process/sighand/whatever reference
entirely and just make reads on a signalfd always dequeue signals for
the current thread.
Duh?! ...
You'd lose
On Sun, 2007-06-17 at 16:49 -0700, Davide Libenzi wrote:
> On Sun, 17 Jun 2007, Nicholas Miell wrote:
>
> > On Sun, 2007-06-17 at 10:01 -0700, Davide Libenzi wrote:
> > > On Sun, 17 Jun 2007, Nicholas Miell wrote:
> > >
> > > > On Sat, 2007-
On Sun, 2007-06-17 at 10:01 -0700, Davide Libenzi wrote:
> On Sun, 17 Jun 2007, Nicholas Miell wrote:
>
> > On Sat, 2007-06-16 at 20:33 -0700, Linus Torvalds wrote:
> > > In a stunning turn of events, I've actually been able to make another -rc
> > > release desp
se
> out there!
>
signalfd still has the broken behavior w.r.t. signal delivery to
threads.
Is this going to get fixed before 2.6.22 proper is released, or should
it just be disabled entirely so no userspace apps grow to depend on
current wrong behavior?
--
Nicholas Miell <[EMAIL PROTECTED]>
there!
signalfd still has the broken behavior w.r.t. signal delivery to
threads.
Is this going to get fixed before 2.6.22 proper is released, or should
it just be disabled entirely so no userspace apps grow to depend on
current wrong behavior?
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from
On Sun, 2007-06-17 at 10:01 -0700, Davide Libenzi wrote:
On Sun, 17 Jun 2007, Nicholas Miell wrote:
On Sat, 2007-06-16 at 20:33 -0700, Linus Torvalds wrote:
In a stunning turn of events, I've actually been able to make another -rc
release despite all the discussion (*cough*flaming
On Sun, 2007-06-17 at 16:49 -0700, Davide Libenzi wrote:
On Sun, 17 Jun 2007, Nicholas Miell wrote:
On Sun, 2007-06-17 at 10:01 -0700, Davide Libenzi wrote:
On Sun, 17 Jun 2007, Nicholas Miell wrote:
On Sat, 2007-06-16 at 20:33 -0700, Linus Torvalds wrote:
In a stunning turn
mprotect and munmap.
I think he's asking for a way to copy an existing mapping, which does
sound genuinely useful. (i.e. mremap(ptr, size, size, MREMAP_COPY), with
no need to mess with files to get multiple mappings of the same region)
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To un
he's asking for a way to copy an existing mapping, which does
sound genuinely useful. (i.e. mremap(ptr, size, size, MREMAP_COPY), with
no need to mess with files to get multiple mappings of the same region)
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
l waiting for signal delivery and the error
is caused by the signal delivery mechanism itself (i.e. a bad pointer
passed to read/select/poll/epoll_wait/etc.) and thus the signal can't be
delivered
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "
On Tue, 2007-06-05 at 17:37 -0700, Davide Libenzi wrote:
> On Tue, 5 Jun 2007, Nicholas Miell wrote:
>
> > On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
> > > On Tue, 5 Jun 2007, Nicholas Miell wrote:
> > >
> > > > Yes, that's certainly wr
On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
> On Tue, 5 Jun 2007, Nicholas Miell wrote:
>
> > Yes, that's certainly wrong, but that's an implementation issue. I was
> > more concerned about the design of the API.
> >
> > Naively, I would expect a reads
On Tue, 2007-06-05 at 17:27 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-06-04 at 23:09 -0700, Nicholas Miell wrote:
> > signalfd() doesn't deliver thread-targeted signals to the wrong
> > threads,
> > does it?
> >
> > Hmm.
> >
> > It loo
actually calls read()).
Which is weird, to say the least. Definitely needs to be noted in the
man page, which doesn't seem to exist yet.
Is there a reason why signalfd() doesn't behave like regular signals in
this regard?
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from
.
Is there a reason why signalfd() doesn't behave like regular signals in
this regard?
--
Nicholas Miell [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/majordomo-info.html
On Tue, 2007-06-05 at 17:27 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2007-06-04 at 23:09 -0700, Nicholas Miell wrote:
signalfd() doesn't deliver thread-targeted signals to the wrong
threads,
does it?
Hmm.
It looks like reading from a signalfd will give you either
process
On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
On Tue, 5 Jun 2007, Nicholas Miell wrote:
Yes, that's certainly wrong, but that's an implementation issue. I was
more concerned about the design of the API.
Naively, I would expect a reads on a signalfd to return either process
On Tue, 2007-06-05 at 17:37 -0700, Davide Libenzi wrote:
On Tue, 5 Jun 2007, Nicholas Miell wrote:
On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
On Tue, 5 Jun 2007, Nicholas Miell wrote:
Yes, that's certainly wrong, but that's an implementation issue. I was
more
the signal can't be
delivered
--
Nicholas Miell [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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
t; #define O_NOATIME0100
> #endif
> +#ifndef O_CLOEXEC
> +#define O_CLOEXEC0200/* set close_on_exec */
> +#endif
> #ifndef O_NDELAY
> #define O_NDELAY O_NONBLOCK
> #endif
O_CLOSEONEXEC, perhaps?
We don't want to create another "creat&qu
0100
#endif
+#ifndef O_CLOEXEC
+#define O_CLOEXEC0200/* set close_on_exec */
+#endif
#ifndef O_NDELAY
#define O_NDELAY O_NONBLOCK
#endif
O_CLOSEONEXEC, perhaps?
We don't want to create another creat here... :)
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe
- Ted
The AMD64 psABI requires binaries to work with any page size up to 64k.
Whether that's true in practice is another matter entirely, of course.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
that's true in practice is another matter entirely, of course.
--
Nicholas Miell [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/majordomo-info.html
Please read
(sorry for the duplicate Ingo, this time I managed to Repy to All)
On Sat, 2007-03-17 at 08:45 +0100, Ingo Molnar wrote:
> * Nicholas Miell <[EMAIL PROTECTED]> wrote:
>
> > The X people have plans for how to go about fixing this, [...]
>
> then we'll first have
te.
>
The changes will probably be entirely server-side anyway, so stray
ancient libraries won't be a problem.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
server-side anyway, so stray
ancient libraries won't be a problem.
--
Nicholas Miell [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/majordomo-info.html
Please read
(sorry for the duplicate Ingo, this time I managed to Repy to All)
On Sat, 2007-03-17 at 08:45 +0100, Ingo Molnar wrote:
* Nicholas Miell [EMAIL PROTECTED] wrote:
The X people have plans for how to go about fixing this, [...]
then we'll first have wait for those X changes to at least
On Sat, 2007-03-17 at 06:56 +0100, Mike Galbraith wrote:
> On Fri, 2007-03-16 at 21:24 -0700, Nicholas Miell wrote:
>
> > Sorry, I haven't really been following this thread and now I'm confused.
> >
> > You're saying that it's somehow the scheduler's fault that X isn't
ion.
>
> If this is your final answer to the problem space, I am done testing,
> and as far as _I_ am concerned, your scheduler is an utter failure.
>
Sorry, I haven't really been following this thread and now I'm confused.
You're saying that it's somehow the scheduler's fault that X isn'
running with a high enough priority?
--
Nicholas Miell [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/majordomo-info.html
Please read the FAQ at http://www.tux.org
On Sat, 2007-03-17 at 06:56 +0100, Mike Galbraith wrote:
On Fri, 2007-03-16 at 21:24 -0700, Nicholas Miell wrote:
Sorry, I haven't really been following this thread and now I'm confused.
You're saying that it's somehow the scheduler's fault that X isn't
running with a high enough
platforms.
(This just works in C because C makes NULL ((void*)0) is thus is the
right size. In C++, the 0 ends up being an int instead of a pointer when
passed to a varargs function, and things tend to blow up when they read
the garbage high bits. Of course, nobody else does this, so you still
have t
On Sun, 2007-03-11 at 16:50 -0700, Nicholas Miell wrote:
> You should probably make it behave like the other things that use
> itimerspec, just to avoid confusion -- i.e. timers are relative by
> default, there's a flag that makes them absolute, they expire when
> it_value specifies
spec, just to avoid confusion -- i.e. timers are relative by
default, there's a flag that makes them absolute, they expire when
it_value specifies, and repeat every it_interval nanoseconds if
it_interval is non-zero.
i.e.
int timerfd(int ufd, int clockid, int flags, const struct timespec
*utmr);
of
relative (and no TFD_TIMER_REL or TFD_TIMER_SEQ at all).
--
Nicholas Miell [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/majordomo-info.html
Please read the FAQ
On Sun, 2007-03-11 at 16:50 -0700, Nicholas Miell wrote:
You should probably make it behave like the other things that use
itimerspec, just to avoid confusion -- i.e. timers are relative by
default, there's a flag that makes them absolute, they expire when
it_value specifies, and repeat every
the garbage high bits. Of course, nobody else does this, so you still
have to use (void*)NULL to be portable.)
--
Nicholas Miell [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
On Sat, 2007-03-10 at 21:31 -0800, Linus Torvalds wrote:
>
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> >
> > Ah, I see. You're just interested in fds as a generic handle concept,
> > and not a more Plan 9 type thing.
>
> Indeed. It's a "handle".
&
On Sat, 2007-03-10 at 17:57 -0800, Davide Libenzi wrote:
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
>
> > If that's the goal, somebody should start thinking about reducing the
> > contents of struct file to the bare minimum (i.e. not much more than a
> > file_operatio
On Sat, 2007-03-10 at 16:35 -0800, Linus Torvalds wrote:
>
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> > >
> > > I'd actually much rather do POSIX timers the other way around: associate
> > > a
> > > generic notification mechanism with the
On Sat, 2007-03-10 at 14:42 -0800, Linus Torvalds wrote:
>
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> >
> > Care to elaborate on why they're a horrible crock?
>
> It's a *classic* case of an interface that tries to do everything under
> the sun.
>
> Here'
On Sat, 2007-03-10 at 13:44 -0800, Linus Torvalds wrote:
>
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> >
> > That's what the sigevent structure is for -- to describe how events
> > should be signaled to userspace, whether by signal delivery, thread
> > creation,
On Sat, 2007-03-10 at 12:41 -0800, Davide Libenzi wrote:
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
>
> > Try reading the timer_create man page.
> >
> > In short, you're limited to a single clock, so you can't set timers
> > based on wall-clock time (subject to N
On Fri, 2007-03-09 at 23:36 -0800, Davide Libenzi wrote:
> On Fri, 9 Mar 2007, Nicholas Miell wrote:
>
> > On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
> > > On Fri, 9 Mar 2007, Nicholas Miell wrote:
> > > >
> > > > So extend the existing
On Fri, 2007-03-09 at 23:36 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
So extend the existing POSIX timer API to deliver expiry events via a
fd
On Sat, 2007-03-10 at 12:41 -0800, Davide Libenzi wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
Try reading the timer_create man page.
In short, you're limited to a single clock, so you can't set timers
based on wall-clock time (subject to NTP correction), monotomic time
On Sat, 2007-03-10 at 13:44 -0800, Linus Torvalds wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
That's what the sigevent structure is for -- to describe how events
should be signaled to userspace, whether by signal delivery, thread
creation, or queuing to event completion ports
On Sat, 2007-03-10 at 14:42 -0800, Linus Torvalds wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
Care to elaborate on why they're a horrible crock?
It's a *classic* case of an interface that tries to do everything under
the sun.
Here's a clue: look at any system call that takes
On Sat, 2007-03-10 at 16:35 -0800, Linus Torvalds wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
I'd actually much rather do POSIX timers the other way around: associate
a
generic notification mechanism with the file descriptor, and then
implement posix_timer_create
On Sat, 2007-03-10 at 17:57 -0800, Davide Libenzi wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
If that's the goal, somebody should start thinking about reducing the
contents of struct file to the bare minimum (i.e. not much more than a
file_operations pointer).
That's already
On Sat, 2007-03-10 at 21:31 -0800, Linus Torvalds wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
Ah, I see. You're just interested in fds as a generic handle concept,
and not a more Plan 9 type thing.
Indeed. It's a handle.
UNIX has pid's for process handles, and file
On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
> On Fri, 9 Mar 2007, Nicholas Miell wrote:
>
> > On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote:
> > > On Fri, 9 Mar 2007, Nicholas Miell wrote:
> > >
> > > > Why d
On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote:
> On Fri, 9 Mar 2007, Nicholas Miell wrote:
>
> > Why did you ignore the existing POSIX timer API?
>
> The existing POSIX API is a standard and a very good one. Too bad it does
> not deliver to files. The timerf
call
> to read(2). The read(2) call supportes the O_NONBLOCK flag too, and EAGAIN
> will be returned if no ticks happened.
> A quick test program, shows timerfd working correctly on my amd64 box:
>
> http://www.xmailserver.org/timerfd-test.c
>
Why did you ignore the ex
you ignore the existing POSIX timer API?
--
Nicholas Miell [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/majordomo-info.html
Please read the FAQ at http
On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
Why did you ignore the existing POSIX timer API?
The existing POSIX API is a standard and a very good one. Too bad it does
not deliver to files. The timerfd code is, as you can probably
On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
Why did you ignore the existing POSIX timer API?
The existing POSIX API
> with lots of CPUs (eg: solaris). So there is a real challenge here to try to
> provide something at least as good and universal because we know that it can
> exist. And this is what you finally did : work on a scheduler which ought to
> be
> good with any workload.
Solaris ha
/FIFO/RR/etc. -- is it's own separate component).
--
Nicholas Miell [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/majordomo-info.html
Please read the FAQ at http
On Fri, 2007-03-02 at 16:52 -0800, Davide Libenzi wrote:
> On Fri, 2 Mar 2007, Nicholas Miell wrote:
>
> > The point Ingo was making is that the x86 ABI already requires the FPU
> > context to be saved before *all* function calls.
>
> I've not seen that among Ingo's poin
across function calls, and I'm sure
this is also true of others.
Then there's the other nasty details of new thread creation --
thankfully, the contents of the TLS isn't inherited from the parent
thread, but it still needs to be initialized; not to mention all the
other details involved in pthread crea
involved in pthread creation and destruction.
I don't see any way around the pthread issues other than making a libc
upcall on return from the first system call that blocked.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Fri, 2007-03-02 at 16:52 -0800, Davide Libenzi wrote:
On Fri, 2 Mar 2007, Nicholas Miell wrote:
The point Ingo was making is that the x86 ABI already requires the FPU
context to be saved before *all* function calls.
I've not seen that among Ingo's points, but yeah some status
gh. (And I
suspect this bug has probably been copied to other architectures as
well.)
--
Nicholas Miell <[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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.)
--
Nicholas Miell [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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
macros, you should probably
use the official all-lowercase C99 version.
--
Nicholas Miell <[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/maj
probably
use the official all-lowercase C99 version.
--
Nicholas Miell [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/majordomo-info.html
Please read the FAQ
inux
> kernels that the dcache/icache is precious, and that it's way too eager
> to dump dcache and icache in favour of data blocks. If I could do that,
> this problem would be much, much smaller.
>
> -hpa
Isn't setting the vm.vfs_cache_pressure sysctl below 100 supposed to
that,
this problem would be much, much smaller.
-hpa
Isn't setting the vm.vfs_cache_pressure sysctl below 100 supposed to do
this?
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
1 - 100 of 116 matches
Mail list logo
