Hi,
v3 of this series implements this idea using using a different
approach:
http://lkml.iu.edu/hypermail/linux/kernel/1502.3/00667.html
If that still meets your needs it would be helpful to know in
order to move this forward.
Looking back at your posting, I was concerned about the
test case no
On 02/21/2015 07:24 PM, Eric Wong wrote:
> Jason Baron wrote:
>> On 02/18/2015 12:51 PM, Ingo Molnar wrote:
>>> * Ingo Molnar wrote:
>>>
> [...] However, I think the userspace API change is less
> clear since epoll_wait() doesn't currently have an
> 'input' events argument as epoll_
Jason Baron wrote:
> On 02/18/2015 12:51 PM, Ingo Molnar wrote:
> > * Ingo Molnar wrote:
> >
> >>> [...] However, I think the userspace API change is less
> >>> clear since epoll_wait() doesn't currently have an
> >>> 'input' events argument as epoll_ctl() does.
> >> ... but the change would be
On 02/18/2015 12:51 PM, Ingo Molnar wrote:
> * Ingo Molnar wrote:
>
>>> [...] However, I think the userspace API change is less
>>> clear since epoll_wait() doesn't currently have an
>>> 'input' events argument as epoll_ctl() does.
>> ... but the change would be a bit clearer and somewhat
>> mo
On Feb 18, 2015 9:38 AM, "Jason Baron" wrote:
>
> On 02/18/2015 11:33 AM, Ingo Molnar wrote:
> > * Jason Baron wrote:
> >
> >>> This has two main advantages: firstly it solves the
> >>> O(N) (micro-)problem, but it also more evenly
> >>> distributes events both between task-lists and within
> >>>
Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
> > > [...] However, I think the userspace API change is less
> > > clear since epoll_wait() doesn't currently have an
> > > 'input' events argument as epoll_ctl() does.
> >
> > ... but the change would be a bit clearer and somewhat
> > more fle
* Ingo Molnar wrote:
> > [...] However, I think the userspace API change is less
> > clear since epoll_wait() doesn't currently have an
> > 'input' events argument as epoll_ctl() does.
>
> ... but the change would be a bit clearer and somewhat
> more flexible: LIFO or FIFO queueing, right?
>
* Jason Baron wrote:
> So in the case of multiple threads per epoll set, we
> currently add to the head of wakeup queue exclusively in
> 'epoll_wait()', and then subsequently remove from the
> queue once 'epoll_wait()' returns. So I don't think this
> patch addresses balancing on a per epoll
On 02/18/2015 11:33 AM, Ingo Molnar wrote:
> * Jason Baron wrote:
>
>>> This has two main advantages: firstly it solves the
>>> O(N) (micro-)problem, but it also more evenly
>>> distributes events both between task-lists and within
>>> epoll groups as tasks as well.
>> Its solving 2 issues - sp
* Jason Baron wrote:
> > This has two main advantages: firstly it solves the
> > O(N) (micro-)problem, but it also more evenly
> > distributes events both between task-lists and within
> > epoll groups as tasks as well.
>
> Its solving 2 issues - spurious wakeups, and more even
> loading of
On 02/18/2015 03:07 AM, Ingo Molnar wrote:
> * Jason Baron wrote:
>
>> Epoll file descriptors that are added to a shared wakeup
>> source are always added in a non-exclusive manner. That
>> means that when we have multiple epoll fds attached to a
>> shared wakeup source they are all woken up. T
* Jason Baron wrote:
> Epoll file descriptors that are added to a shared wakeup
> source are always added in a non-exclusive manner. That
> means that when we have multiple epoll fds attached to a
> shared wakeup source they are all woken up. This can lead
> to excessive cpu usage and uneven
Epoll file descriptors that are added to a shared wakeup source are always
added in a non-exclusive manner. That means that when we have multiple epoll
fds attached to a shared wakeup source they are all woken up. This can
lead to excessive cpu usage and uneven load distribution.
This patch introd
13 matches
Mail list logo
