[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-serial
Subject:    Re: pty master not woken up?
From:       Peter Hurley <peter () hurleysoftware ! com>
Date:       2015-09-30 21:35:47
Message-ID: 560C55B3.9060703 () hurleysoftware ! com
[Download RAW message or body]

On 09/30/2015 05:26 PM, Francesco Ruggeri wrote:
> On Wed, Sep 30, 2015 at 12:36 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
>>
>> What arch/platform are you seeing this on?
> 
> x86_64 on Supermicro servers with two Xeon CPUs, 8 or 12 cores each,
> hyperthreading.
> 
> I do not know when I will have a chance to try this on 4.X.
> I have not worked on this for a while now, but here are some updates
> about 3.18.19
> since my original post.
> - I had to apply the same logic to n_tty_read.
> - Using the memory barriers did not help (but I am still curious about
> that logic).

Yeah, lack of memory barriers would not explain your observation on x86/64
because the situation you hypothesized [1] is not possible on x86/64 CPUs.
Further, the compiler should not be able to re-order those operations either;
what compiler are you using?  For completeness, would you send me a mixed
listing of drivers/tty/n_tty.c for that server/kernel/compiler so I can
eliminate compiler reordering as the problem.

Regards,
Peter Hurley


[1]

On 08/28/2015 01:06 PM, Francesco Ruggeri wrote:
> It looks like the logic used is like this:
> 
> producer (flush_to_ldisc)	consumer (select/n_tty_poll)
> 
> advance index in read_buf	add_wait_queue
> (full memory barrier here?)	(full memory barrier here?)
> if waitqueue_active()		if !input_available_p()
> 	wake up consumer		wait

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]