Hello,
Willy Tarreau wrote:
>> The thing is that the synchronization overhead is something you'll have
>> to pay anyway to support multiple processors.
>
> But you don't need to sync *everything*. It is doable to have 1 thread
> per processor, each with their own data, and sync the minimum inform
On Wed, May 30, 2007 at 07:12:01PM +0900, Tejun Heo wrote:
> Hello,
>
> Willy Tarreau wrote:
> > In my experience, it's not much the context switch by itself which
> > causes performance degradation, but the fact that with threads, you
> > have to put mutexes everywhere. And frankly, walking a lis
On Wed, May 30, 2007 at 01:07:08AM -0700, David Schwartz wrote:
>
> > In my experience, it's not much the context switch by itself which causes
> > performance degradation, but the fact that with threads, you have to put
> > mutexes everywhere. And frankly, walking a list with locks everywhere
> >
Hello,
Willy Tarreau wrote:
> In my experience, it's not much the context switch by itself which
> causes performance degradation, but the fact that with threads, you
> have to put mutexes everywhere. And frankly, walking a list with
> locks everywhere is quite slower than doing it in one run at a
> In my experience, it's not much the context switch by itself which causes
> performance degradation, but the fact that with threads, you have to put
> mutexes everywhere. And frankly, walking a list with locks everywhere
> is quite slower than doing it in one run at a rate of 3 or 4 cycles per
>
I mostly agree with your comments, so I'm only responding to the points I
disagree with.
> So in fact, converting a threaded program to a pure async model should
> not improve it much because of the initial architectural design. But a
> program written from scratch to be purely async should perfo
On Wed, May 30, 2007 at 04:35:56AM +0900, Tejun Heo wrote:
> David Schwartz wrote:
> >> I want to know in detail about , what the events (epoll or /dev/poll or
> >> select ) achieve in contrast to thread per client.
> >>
> >> i can have a thread per client and use send and recv system call directl
David Schwartz wrote:
>> I want to know in detail about , what the events (epoll or /dev/poll or
>> select ) achieve in contrast to thread per client.
>>
>> i can have a thread per client and use send and recv system call directly
>> right? Why do i go for these event mechanisms?
>>
>> Please help
> Hello all,
>
> I want to know in detail about , what the events (epoll or /dev/poll or
> select ) achieve in contrast to thread per client.
>
> i can have a thread per client and use send and recv system call directly
> right? Why do i go for these event mechanisms?
>
> Please help me to unders
Hi Arunachalam,
On Saturday 26 May 2007, Arunachalam wrote:
> I want to know in detail about , what the events (epoll or /dev/poll or
> select ) achieve in contrast to thread per client.
>
> i can have a thread per client and use send and recv system call directly
> right? Why do i go for these
Hello all,
I want to know in detail about , what the events (epoll or /dev/poll or
select ) achieve in contrast to thread per client.
i can have a thread per client and use send and recv system call directly
right? Why do i go for these event mechanisms?
Please help me to understand this.
Th
11 matches
Mail list logo
