On Wed, Mar 07, 2007 at 03:21:19PM -0300, Kirk Kuchov ([EMAIL PROTECTED]) wrote:
> On 3/7/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> >* Kirk Kuchov <[EMAIL PROTECTED]> wrote:
> >
> >> I don't believe I'm wasting my time explaining this. They don't exist
> >> as /dev/null, they are just
On 3/7/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Kirk Kuchov <[EMAIL PROTECTED]> wrote:
> I don't believe I'm wasting my time explaining this. They don't exist
> as /dev/null, they are just fucking _LINKS_.
[...]
> > Either stop flaming kernel developers or become one. It is that
> >
On Wed, Mar 07 2007, Kirk Kuchov wrote:
> On 3/7/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> >* Kirk Kuchov <[EMAIL PROTECTED]> wrote:
> >
> >> I don't believe I'm wasting my time explaining this. They don't exist
> >> as /dev/null, they are just fucking _LINKS_.
> >[...]
> >> > Either stop
* Kirk Kuchov <[EMAIL PROTECTED]> wrote:
> I don't believe I'm wasting my time explaining this. They don't exist
> as /dev/null, they are just fucking _LINKS_.
[...]
> > Either stop flaming kernel developers or become one. It is that
> > simple.
>
> If I were to become a kernel developer I
On Wed, 7 Mar 2007, Kirk Kuchov wrote:
>
> I don't believe I'm wasting my time explaining this. They don't exist
> as /dev/null, they are just fucking _LINKS_. I could even "ln -s
> /proc/self/fd/0 sucker". A real /dev/stdout can/could even exist, but
> that's not the point!
Actually, one
On 3/7/07, Al Boldi <[EMAIL PROTECTED]> wrote:
Kirk Kuchov wrote:
> > Either stop flaming kernel developers or become one. It is that
> > simple.
>
> If I were to become a kernel developer I would stick with FreeBSD. At
> least they have kqueue for about seven years now.
I have been playing
Kirk Kuchov wrote:
> > Either stop flaming kernel developers or become one. It is that
> > simple.
>
> If I were to become a kernel developer I would stick with FreeBSD. At
> least they have kqueue for about seven years now.
I have been playing with this thought for quite some time. The
On 3/6/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> >As for why common abstractions like file are a good thing, think about why
> >having "/dev/null" is cleaner that having a special plug DEVNULL_FD fd
> >value to be plugged everywhere,
>
> This is a stupid comparaison. By your logic we should
On 3/6/07, Pavel Machek [EMAIL PROTECTED] wrote:
As for why common abstractions like file are a good thing, think about why
having /dev/null is cleaner that having a special plug DEVNULL_FD fd
value to be plugged everywhere,
This is a stupid comparaison. By your logic we should also have
Kirk Kuchov wrote:
Either stop flaming kernel developers or become one. It is that
simple.
If I were to become a kernel developer I would stick with FreeBSD. At
least they have kqueue for about seven years now.
I have been playing with this thought for quite some time. The question is,
On 3/7/07, Al Boldi [EMAIL PROTECTED] wrote:
Kirk Kuchov wrote:
Either stop flaming kernel developers or become one. It is that
simple.
If I were to become a kernel developer I would stick with FreeBSD. At
least they have kqueue for about seven years now.
I have been playing with this
On Wed, 7 Mar 2007, Kirk Kuchov wrote:
I don't believe I'm wasting my time explaining this. They don't exist
as /dev/null, they are just fucking _LINKS_. I could even ln -s
/proc/self/fd/0 sucker. A real /dev/stdout can/could even exist, but
that's not the point!
Actually, one large
* Kirk Kuchov [EMAIL PROTECTED] wrote:
I don't believe I'm wasting my time explaining this. They don't exist
as /dev/null, they are just fucking _LINKS_.
[...]
Either stop flaming kernel developers or become one. It is that
simple.
If I were to become a kernel developer I would stick
On 3/7/07, Ingo Molnar [EMAIL PROTECTED] wrote:
* Kirk Kuchov [EMAIL PROTECTED] wrote:
I don't believe I'm wasting my time explaining this. They don't exist
as /dev/null, they are just fucking _LINKS_.
[...]
Either stop flaming kernel developers or become one. It is that
simple.
If I
On Wed, Mar 07 2007, Kirk Kuchov wrote:
On 3/7/07, Ingo Molnar [EMAIL PROTECTED] wrote:
* Kirk Kuchov [EMAIL PROTECTED] wrote:
I don't believe I'm wasting my time explaining this. They don't exist
as /dev/null, they are just fucking _LINKS_.
[...]
Either stop flaming kernel
On Wed, Mar 07, 2007 at 03:21:19PM -0300, Kirk Kuchov ([EMAIL PROTECTED]) wrote:
On 3/7/07, Ingo Molnar [EMAIL PROTECTED] wrote:
* Kirk Kuchov [EMAIL PROTECTED] wrote:
I don't believe I'm wasting my time explaining this. They don't exist
as /dev/null, they are just fucking _LINKS_.
> >As for why common abstractions like file are a good thing, think about why
> >having "/dev/null" is cleaner that having a special plug DEVNULL_FD fd
> >value to be plugged everywhere,
>
> This is a stupid comparaison. By your logic we should also have /dev/stdin,
> /dev/stdout and /dev/stderr.
As for why common abstractions like file are a good thing, think about why
having /dev/null is cleaner that having a special plug DEVNULL_FD fd
value to be plugged everywhere,
This is a stupid comparaison. By your logic we should also have /dev/stdin,
/dev/stdout and /dev/stderr.
Bzzt,
On 3/4/07, Kyle Moffett <[EMAIL PROTECTED]> wrote:
Well, even this far into 2.6, Linus' patch from 2003 still (mostly)
applies; the maintenance cost for this kind of code is virtually
zilch. If it matters that much to you clean it up and make it apply;
add an alarmfd() syscall (another 100
Kirk Kuchov wrote:
[snip]
This is a stupid comparaison. By your logic we should also have /dev/stdin,
/dev/stdout and /dev/stderr.
Well, as a matter of fact (on my system):
# ls -l /dev/std*
lrwxrwxrwx 1 root root 4 Feb 1 2006 /dev/stderr -> fd/2
lrwxrwxrwx 1 root root 4 Feb 1 2006
> From: "Michael K. Edwards" <[EMAIL PROTECTED]>
> Newsgroups: gmane.linux.kernel
> Subject: Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
> Date: Wed, 28 Feb 2007 09:01:07 -0800
Michael,
[]
> In this instance, there didn't seem to be
On Sun, 4 Mar 2007, Kirk Kuchov wrote:
> I don't give a shit.
Here's another good use of /dev/null:
*PLONK*
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On 3/4/07, Davide Libenzi wrote:
On Sun, 4 Mar 2007, Kirk Kuchov wrote:
> On 3/3/07, Davide Libenzi wrote:
> >
> >
> > Those *other* (tons?!?) interfaces can be created *when* the need comes
> > (see Linus signalfd [1] example to show how urgent that was). *When*
> > the need comes, they
On Sun, 4 Mar 2007, Kirk Kuchov wrote:
> On 3/3/07, Davide Libenzi wrote:
> >
> >
> > Those *other* (tons?!?) interfaces can be created *when* the need comes
> > (see Linus signalfd [1] example to show how urgent that was). *When*
> > the need comes, they will work with existing POSIX
On Mar 04, 2007, at 11:23:37, Kirk Kuchov wrote:
So here we are, 2007. epoll() works with files, pipes, sockets,
inotify and anything pollable (file descriptors) but aio, timers,
signals and user-defined event. Can we please get those working
with epoll ? Something as simple as:
[code
On 3/3/07, Davide Libenzi wrote:
Those *other* (tons?!?) interfaces can be created *when* the need comes
(see Linus signalfd [1] example to show how urgent that was). *When*
the need comes, they will work with existing POSIX interfaces, without
requiring your own just-another event interface.
Please don't take this the wrong way, Ray, but I don't think _you_
understand the problem space that people are (or should be) trying to
address here.
Servers want to always, always block. Not on a socket, not on a stat,
not on any _one_ thing, but in a condition where the optimum number of
Please don't take this the wrong way, Ray, but I don't think _you_
understand the problem space that people are (or should be) trying to
address here.
Servers want to always, always block. Not on a socket, not on a stat,
not on any _one_ thing, but in a condition where the optimum number of
On 3/3/07, Davide Libenzi davidel@xmailserver.org wrote:
snip
Those *other* (tons?!?) interfaces can be created *when* the need comes
(see Linus signalfd [1] example to show how urgent that was). *When*
the need comes, they will work with existing POSIX interfaces, without
requiring your own
On Mar 04, 2007, at 11:23:37, Kirk Kuchov wrote:
So here we are, 2007. epoll() works with files, pipes, sockets,
inotify and anything pollable (file descriptors) but aio, timers,
signals and user-defined event. Can we please get those working
with epoll ? Something as simple as:
[code
On Sun, 4 Mar 2007, Kirk Kuchov wrote:
On 3/3/07, Davide Libenzi davidel@xmailserver.org wrote:
snip
Those *other* (tons?!?) interfaces can be created *when* the need comes
(see Linus signalfd [1] example to show how urgent that was). *When*
the need comes, they will work with
On 3/4/07, Davide Libenzi davidel@xmailserver.org wrote:
On Sun, 4 Mar 2007, Kirk Kuchov wrote:
On 3/3/07, Davide Libenzi davidel@xmailserver.org wrote:
snip
Those *other* (tons?!?) interfaces can be created *when* the need comes
(see Linus signalfd [1] example to show how urgent that
On Sun, 4 Mar 2007, Kirk Kuchov wrote:
I don't give a shit.
Here's another good use of /dev/null:
*PLONK*
- Davide
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: Michael K. Edwards [EMAIL PROTECTED]
Newsgroups: gmane.linux.kernel
Subject: Re: [patch 00/13] Syslets, Threadlets, generic AIO support, v3
Date: Wed, 28 Feb 2007 09:01:07 -0800
Michael,
[]
In this instance, there didn't seem to be any harm in sending my
thoughts to LKML as I wrote
Kirk Kuchov wrote:
[snip]
This is a stupid comparaison. By your logic we should also have /dev/stdin,
/dev/stdout and /dev/stderr.
Well, as a matter of fact (on my system):
# ls -l /dev/std*
lrwxrwxrwx 1 root root 4 Feb 1 2006 /dev/stderr - fd/2
lrwxrwxrwx 1 root root 4 Feb 1 2006
On 3/4/07, Kyle Moffett [EMAIL PROTECTED] wrote:
Well, even this far into 2.6, Linus' patch from 2003 still (mostly)
applies; the maintenance cost for this kind of code is virtually
zilch. If it matters that much to you clean it up and make it apply;
add an alarmfd() syscall (another 100 lines
Ihar `Philips` Filipau wrote:
> On 3/3/07, Ray Lee <[EMAIL PROTECTED]> wrote:
>> On 3/3/07, Ihar `Philips` Filipau <[EMAIL PROTECTED]> wrote:
>> > What I'm trying to get to: keep things simple. The proposed
>> > optimization by Ingo does nothing else but allowing AIO to probe file
>> > cache - if
On 3/3/07, Ray Lee <[EMAIL PROTECTED]> wrote:
On 3/3/07, Ihar `Philips` Filipau <[EMAIL PROTECTED]> wrote:
> What I'm trying to get to: keep things simple. The proposed
> optimization by Ingo does nothing else but allowing AIO to probe file
> cache - if data there to go with fast path. So why
On Sat, 3 Mar 2007, Davide Libenzi wrote:
> Those *other* (tons?!?) interfaces can be created *when* the need comes
> (see Linus signalfd [1] example to show how urgent that was). *When*
> the need comes, they will work with existing POSIX interfaces, without
> requiring your own just-another
On Sat, 3 Mar 2007, Evgeniy Polyakov wrote:
> > I was referring to dropping an event directly to a userspace buffer, from
> > the poll callback. If pages are not there, you might sleep, and you can't
> > since the wakeup function holds a spinlock on the waitqueue head while
> > looping through
On 3/3/07, Ihar `Philips` Filipau <[EMAIL PROTECTED]> wrote:
What I'm trying to get to: keep things simple. The proposed
optimization by Ingo does nothing else but allowing AIO to probe file
cache - if data there to go with fast path. So why not to implement
what the people want - probing of
On Sat, Mar 03, 2007 at 10:46:59AM -0800, Davide Libenzi
(davidel@xmailserver.org) wrote:
> On Sat, 3 Mar 2007, Evgeniy Polyakov wrote:
>
> > > You've to excuse me if my memory is bad, but IIRC the whole discussion
> > > and loong benchmark feast born with you throwing a benchmark at Ingo
> >
On Sat, 3 Mar 2007, Evgeniy Polyakov wrote:
> > You've to excuse me if my memory is bad, but IIRC the whole discussion
> > and loong benchmark feast born with you throwing a benchmark at Ingo
> > (with kevent showing a 1.9x performance boost WRT epoll), not with you
> > making any other point.
On 3/3/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >Threadlets can work with any functionas a base - if it would be
> >recv-like it will limit possible case for parallel programming, so you
> >can code anything in threadlets - it is not only about IO.
>
> What I'm trying to get to: keep
On Sat, Mar 03, 2007 at 11:58:17AM +0100, Ihar `Philips` Filipau ([EMAIL
PROTECTED]) wrote:
> On 3/3/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >On Fri, Mar 02, 2007 at 08:20:26PM +0100, Ihar `Philips` Filipau
> >([EMAIL PROTECTED]) wrote:
> >> I'm not well versed in modern kernel
On 3/3/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
On Fri, Mar 02, 2007 at 08:20:26PM +0100, Ihar `Philips` Filipau ([EMAIL
PROTECTED]) wrote:
> I'm not well versed in modern kernel development discussions, and
> since you have put the thing into the networked context anyway, can
> you
On Fri, Mar 02, 2007 at 09:28:10AM -0800, Davide Libenzi
(davidel@xmailserver.org) wrote:
> On Fri, 2 Mar 2007, Evgeniy Polyakov wrote:
>
> > do we really want to have per process signalfs, timerfs and so on - each
> > simple structure must be bound to a file, which becomes too cost.
>
> I may
On Fri, Mar 02, 2007 at 09:13:40AM -0800, Davide Libenzi
(davidel@xmailserver.org) wrote:
> On Fri, 2 Mar 2007, Evgeniy Polyakov wrote:
>
> > On Thu, Mar 01, 2007 at 11:31:14AM -0800, Davide Libenzi
> > (davidel@xmailserver.org) wrote:
> > > On Thu, 1 Mar 2007, Evgeniy Polyakov wrote:
> > >
>
On Sat, 3 Mar 2007, Ingo Molnar wrote:
> * Davide Libenzi wrote:
>
> > [...] Status word and control bits should not be changed from
> > underneath userspace AFAIK. [...]
>
> Note that the control bits do not just magically change during normal
> FPU use. It's a bit like
On Sat, 3 Mar 2007, Ingo Molnar wrote:
* Davide Libenzi davidel@xmailserver.org wrote:
[...] Status word and control bits should not be changed from
underneath userspace AFAIK. [...]
Note that the control bits do not just magically change during normal
FPU use. It's a bit like
On Fri, Mar 02, 2007 at 09:13:40AM -0800, Davide Libenzi
(davidel@xmailserver.org) wrote:
On Fri, 2 Mar 2007, Evgeniy Polyakov wrote:
On Thu, Mar 01, 2007 at 11:31:14AM -0800, Davide Libenzi
(davidel@xmailserver.org) wrote:
On Thu, 1 Mar 2007, Evgeniy Polyakov wrote:
Ingo, do
On Fri, Mar 02, 2007 at 09:28:10AM -0800, Davide Libenzi
(davidel@xmailserver.org) wrote:
On Fri, 2 Mar 2007, Evgeniy Polyakov wrote:
do we really want to have per process signalfs, timerfs and so on - each
simple structure must be bound to a file, which becomes too cost.
I may be old
On 3/3/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Fri, Mar 02, 2007 at 08:20:26PM +0100, Ihar `Philips` Filipau ([EMAIL
PROTECTED]) wrote:
I'm not well versed in modern kernel development discussions, and
since you have put the thing into the networked context anyway, can
you please
On Sat, Mar 03, 2007 at 11:58:17AM +0100, Ihar `Philips` Filipau ([EMAIL
PROTECTED]) wrote:
On 3/3/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Fri, Mar 02, 2007 at 08:20:26PM +0100, Ihar `Philips` Filipau
([EMAIL PROTECTED]) wrote:
I'm not well versed in modern kernel development
On 3/3/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Threadlets can work with any functionas a base - if it would be
recv-like it will limit possible case for parallel programming, so you
can code anything in threadlets - it is not only about IO.
What I'm trying to get to: keep things
On Sat, 3 Mar 2007, Evgeniy Polyakov wrote:
You've to excuse me if my memory is bad, but IIRC the whole discussion
and loong benchmark feast born with you throwing a benchmark at Ingo
(with kevent showing a 1.9x performance boost WRT epoll), not with you
making any other point.
So,
On Sat, Mar 03, 2007 at 10:46:59AM -0800, Davide Libenzi
(davidel@xmailserver.org) wrote:
On Sat, 3 Mar 2007, Evgeniy Polyakov wrote:
You've to excuse me if my memory is bad, but IIRC the whole discussion
and loong benchmark feast born with you throwing a benchmark at Ingo
(with
On 3/3/07, Ihar `Philips` Filipau [EMAIL PROTECTED] wrote:
What I'm trying to get to: keep things simple. The proposed
optimization by Ingo does nothing else but allowing AIO to probe file
cache - if data there to go with fast path. So why not to implement
what the people want - probing of
On Sat, 3 Mar 2007, Evgeniy Polyakov wrote:
I was referring to dropping an event directly to a userspace buffer, from
the poll callback. If pages are not there, you might sleep, and you can't
since the wakeup function holds a spinlock on the waitqueue head while
looping through the
On Sat, 3 Mar 2007, Davide Libenzi wrote:
Those *other* (tons?!?) interfaces can be created *when* the need comes
(see Linus signalfd [1] example to show how urgent that was). *When*
the need comes, they will work with existing POSIX interfaces, without
requiring your own just-another
On 3/3/07, Ray Lee [EMAIL PROTECTED] wrote:
On 3/3/07, Ihar `Philips` Filipau [EMAIL PROTECTED] wrote:
What I'm trying to get to: keep things simple. The proposed
optimization by Ingo does nothing else but allowing AIO to probe file
cache - if data there to go with fast path. So why not to
Ihar `Philips` Filipau wrote:
On 3/3/07, Ray Lee [EMAIL PROTECTED] wrote:
On 3/3/07, Ihar `Philips` Filipau [EMAIL PROTECTED] wrote:
What I'm trying to get to: keep things simple. The proposed
optimization by Ingo does nothing else but allowing AIO to probe file
cache - if data there to go
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Note that the control bits do not just magically change during normal
> FPU use. It's a bit like sys_setsid()/iopl/etc., it makes little sense
> to change those per-thread anyway. This is a non-issue anyway - what is
> important is that the big bulk
* Davide Libenzi wrote:
> [...] Status word and control bits should not be changed from
> underneath userspace AFAIK. [...]
Note that the control bits do not just magically change during normal
FPU use. It's a bit like sys_setsid()/iopl/etc., it makes little sense
to change those per-thread
On Fri, 2 Mar 2007, Nicholas Miell wrote:
> 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
On Fri, Mar 02, 2007 at 05:36:01PM -0800, Nicholas Miell wrote:
> > as an asynchronous context helps alot: the classic gcc convention for
> > FPU use & function calls should apply: gcc does not call an external
> > function with an in-use FPU stack/register, it always neatly unuses it,
> > as
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
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 is caller
saved. But, aren't things like status word and control
On Fri, 2007-03-02 at 12:53 -0800, Davide Libenzi wrote:
> On Fri, 2 Mar 2007, Ingo Molnar wrote:
>
> >
> > * Davide Libenzi wrote:
> >
> > > I think that the "dirty" FPU context must, at least, follow the new
> > > head. That's what the userspace sees, and you don't want an async_exec
> > >
On 3/2/07, Davide Libenzi wrote:
For threadlets, it might be. Now think about a task wanting to dispatch N
parallel AIO requests as N independent syslets.
Think about this task having USEDFPU set, so the FPU context is dirty.
When it returns from async_exec, with one of the requests being
On Fri, 2 Mar 2007, Ingo Molnar wrote:
>
> * Davide Libenzi wrote:
>
> > I think that the "dirty" FPU context must, at least, follow the new
> > head. That's what the userspace sees, and you don't want an async_exec
> > to re-emerge with a different FPU context.
>
> well. I think there's
* Davide Libenzi wrote:
> I think that the "dirty" FPU context must, at least, follow the new
> head. That's what the userspace sees, and you don't want an async_exec
> to re-emerge with a different FPU context.
well. I think there's some confusion about terminology, so please let me
On Fri, 2 Mar 2007, Ingo Molnar wrote:
>
> * Davide Libenzi wrote:
>
> > [...] We're still missing proper FPU context switch in the
> > move_user_context(). [...]
>
> yeah - i'm starting to be of the opinion that the FPU context should
> stay with the threadlet, exclusively. I.e. when
* Davide Libenzi wrote:
> [...] We're still missing proper FPU context switch in the
> move_user_context(). [...]
yeah - i'm starting to be of the opinion that the FPU context should
stay with the threadlet, exclusively. I.e. when calling a threadlet, the
'outer loop' (the event loop)
On Fri, 2 Mar 2007, Davide Libenzi wrote:
> And if you really feel raw about the single O(nready) loop that epoll
> currently does, a new epoll_wait2 (or whatever) API could be used to
> deliver the event directly into a userspace buffer [1], directly from the
> poll callback, w/out extra
On Fri, 2 Mar 2007, Ingo Molnar wrote:
> > After your changes epoll increased to 5k.
>
> Can we please stop this pointless episode of benchmarketing, where every
> mail of yours shows different results and you even deny having said
> something which you clearly said just a few days ago? At
On Fri, 2 Mar 2007, Evgeniy Polyakov wrote:
> do we really want to have per process signalfs, timerfs and so on - each
> simple structure must be bound to a file, which becomes too cost.
I may be old school, but if you ask me, and if you *really* want those
events, yes. Reason? Unix's
On Fri, 2 Mar 2007, Evgeniy Polyakov wrote:
> On Thu, Mar 01, 2007 at 11:31:14AM -0800, Davide Libenzi
> (davidel@xmailserver.org) wrote:
> > On Thu, 1 Mar 2007, Evgeniy Polyakov wrote:
> >
> > > Ingo, do you really think I will send mails with faked benchmarks? :))
> >
> > I don't think he
On Fri, Mar 02, 2007 at 11:57:13AM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > > > > [...] The numbers are still highly suspect - and we are already
> > > > > down from the prior claim of kevent being almost twice as fast
> > > > > to a
On Fri, Mar 02, 2007 at 11:56:18AM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > Even if kevent has the same speed, it still allows to handle _any_
> > kind of events without any major surgery - a very tiny structure of
> > lock and list
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > > > [...] The numbers are still highly suspect - and we are already
> > > > down from the prior claim of kevent being almost twice as fast
> > > > to a 25% difference.
> > >
> > > Btw, there were never almost twice perfromance increase - epoll
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> Even if kevent has the same speed, it still allows to handle _any_
> kind of events without any major surgery - a very tiny structure of
> lock and list head and you can process your own kernel event in
> userspace with timers, signals, io
On Fri, Mar 02, 2007 at 11:27:14AM +0100, Pavel Machek ([EMAIL PROTECTED])
wrote:
> Maybe. It is not up to me to decide. But "it is faster" is _not_ the
> only merge criterium.
Of course not!
Even if kevent has the same speed, it still allows to handle _any_ kind
of events without any major
Hi!
> > > > If you can replace them with something simpler, and no worse than 10%
> > > > slower in worst case, then go ahead. (We actually tried to do that at
> > > > some point, only to realize that efence stresses vm subsystem in very
> > > > unexpected/unfriendly way).
> > >
> > > Agh, only
On Thu, Mar 01, 2007 at 11:31:14AM -0800, Davide Libenzi
(davidel@xmailserver.org) wrote:
> On Thu, 1 Mar 2007, Evgeniy Polyakov wrote:
>
> > Ingo, do you really think I will send mails with faked benchmarks? :))
>
> I don't think he ever implied that. He was only suggesting that when you
>
On Thu, Mar 01, 2007 at 11:31:14AM -0800, Davide Libenzi
(davidel@xmailserver.org) wrote:
On Thu, 1 Mar 2007, Evgeniy Polyakov wrote:
Ingo, do you really think I will send mails with faked benchmarks? :))
I don't think he ever implied that. He was only suggesting that when you
post
Hi!
If you can replace them with something simpler, and no worse than 10%
slower in worst case, then go ahead. (We actually tried to do that at
some point, only to realize that efence stresses vm subsystem in very
unexpected/unfriendly way).
Agh, only 10% in the worst case.
On Fri, Mar 02, 2007 at 11:27:14AM +0100, Pavel Machek ([EMAIL PROTECTED])
wrote:
Maybe. It is not up to me to decide. But it is faster is _not_ the
only merge criterium.
Of course not!
Even if kevent has the same speed, it still allows to handle _any_ kind
of events without any major surgery
* Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Even if kevent has the same speed, it still allows to handle _any_
kind of events without any major surgery - a very tiny structure of
lock and list head and you can process your own kernel event in
userspace with timers, signals, io events,
* Evgeniy Polyakov [EMAIL PROTECTED] wrote:
[...] The numbers are still highly suspect - and we are already
down from the prior claim of kevent being almost twice as fast
to a 25% difference.
Btw, there were never almost twice perfromance increase - epoll in
my tests
On Fri, Mar 02, 2007 at 11:56:18AM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
* Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Even if kevent has the same speed, it still allows to handle _any_
kind of events without any major surgery - a very tiny structure of
lock and list head and
On Fri, Mar 02, 2007 at 11:57:13AM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
* Evgeniy Polyakov [EMAIL PROTECTED] wrote:
[...] The numbers are still highly suspect - and we are already
down from the prior claim of kevent being almost twice as fast
to a 25% difference.
On Fri, 2 Mar 2007, Evgeniy Polyakov wrote:
On Thu, Mar 01, 2007 at 11:31:14AM -0800, Davide Libenzi
(davidel@xmailserver.org) wrote:
On Thu, 1 Mar 2007, Evgeniy Polyakov wrote:
Ingo, do you really think I will send mails with faked benchmarks? :))
I don't think he ever implied
On Fri, 2 Mar 2007, Evgeniy Polyakov wrote:
do we really want to have per process signalfs, timerfs and so on - each
simple structure must be bound to a file, which becomes too cost.
I may be old school, but if you ask me, and if you *really* want those
events, yes. Reason? Unix's
On Fri, 2 Mar 2007, Ingo Molnar wrote:
After your changes epoll increased to 5k.
Can we please stop this pointless episode of benchmarketing, where every
mail of yours shows different results and you even deny having said
something which you clearly said just a few days ago? At this
On Fri, 2 Mar 2007, Davide Libenzi wrote:
And if you really feel raw about the single O(nready) loop that epoll
currently does, a new epoll_wait2 (or whatever) API could be used to
deliver the event directly into a userspace buffer [1], directly from the
poll callback, w/out extra delivery
* Davide Libenzi davidel@xmailserver.org wrote:
[...] We're still missing proper FPU context switch in the
move_user_context(). [...]
yeah - i'm starting to be of the opinion that the FPU context should
stay with the threadlet, exclusively. I.e. when calling a threadlet, the
'outer loop'
On Fri, 2 Mar 2007, Ingo Molnar wrote:
* Davide Libenzi davidel@xmailserver.org wrote:
[...] We're still missing proper FPU context switch in the
move_user_context(). [...]
yeah - i'm starting to be of the opinion that the FPU context should
stay with the threadlet, exclusively.
* Davide Libenzi davidel@xmailserver.org wrote:
I think that the dirty FPU context must, at least, follow the new
head. That's what the userspace sees, and you don't want an async_exec
to re-emerge with a different FPU context.
well. I think there's some confusion about terminology, so
On Fri, 2 Mar 2007, Ingo Molnar wrote:
* Davide Libenzi davidel@xmailserver.org wrote:
I think that the dirty FPU context must, at least, follow the new
head. That's what the userspace sees, and you don't want an async_exec
to re-emerge with a different FPU context.
well. I think
1 - 100 of 632 matches
Mail list logo
