On 20.03.2013 21:49, Peter Hurley wrote:
> The motivation for changing the workqueue api to allow parallel work
> items on SMP was to fix a class of deadlocks where forward progress
> could not be made due to subtle dependencies between work items
> (actually that potential still exists with self-m
On Wed, 2013-03-20 at 16:47 +0400, Ilya Zykov wrote:
> >> I have little question about flush_to_ldisc().
> >> Does can it be multithreaded?
> >>
> >> I think yes, because on SMP schedule_work() can work on different CPU
> >> paralleled.
> >
> > Yes, the same work item can now run in parallel on S
>> I have little question about flush_to_ldisc().
>> Does can it be multithreaded?
>>
>> I think yes, because on SMP schedule_work() can work on different CPU
>> paralleled.
>
> Yes, the same work item can now run in parallel on SMP since Tejun Heo
> re-did the workqueue implementation on 2.6.36
On Wed, 2013-03-20 at 02:42 +0400, Ilya Zykov wrote:
> On 20.03.2013 0:21, Peter Hurley wrote:
> > Ldisc interface functions must be called with interrupts enabled.
> > Separating the ldisc calls into a helper function simplies the
> > spin lock management.
> >
> > Update the buffer's read index _
On 20.03.2013 0:21, Peter Hurley wrote:
> Ldisc interface functions must be called with interrupts enabled.
> Separating the ldisc calls into a helper function simplies the
> spin lock management.
>
> Update the buffer's read index _after_ the data has been received
> by the ldisc.
>
Hello Peter
Ldisc interface functions must be called with interrupts enabled.
Separating the ldisc calls into a helper function simplies the
spin lock management.
Update the buffer's read index _after_ the data has been received
by the ldisc.
Signed-off-by: Peter Hurley
---
drivers/tty/tty_buffer.c | 28 ++
6 matches
Mail list logo
