On 09/30/2015 05:26 PM, Francesco Ruggeri wrote: > On Wed, Sep 30, 2015 at 12:36 PM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
