Re: Delegating printk work to UART interrupt
Hello Alexander, On Wed, Jul 22, 2015 at 11:08 AM, Alexander wrote: > Hi Arun KS, > Actually, i already saw this one and something similar were tested. I just > trying > to figure out the reasons why generic kernel layer (console_unlock) > implemented > in such way: i.e. why it accounts on immediate busyloop printing? Is it > reliable to > defer such printing to UART interrupts? > Lets try to find out why it is done the way it is. My guess is "it makes printk simple and robust". Because if interrupts are blocked, console should not fail giving the critical information. To change this behavior, we have to change the complete logic in the prink code to adjust with that. Because as of now printk code expects serial drivers returns only after finishing the job. Thanks, Arun > > Thank you. > > On Mon, 20 Jul 2015 09:34:16 +0530 > Arun KS wrote: > > > Hello Alexander, > > > > On Sat, Jul 18, 2015 at 11:23 AM, Alexander > wrote: > > > > > > > > Hi! > > > When i checked how kernel printing works, i mentioned that it takes > > > messages > > > from log_buffer in console_unlock and gives it to call_console_drivers > -> > > > ... > > > -> some uart bsp function. Basically, as i see this BSP realization > tries > > > to flush all message chars in busyloop ... so it waits until > FIFO_NOT_FULL > > > bit will > > > be dropped by UART and it will be able to push the next byte. > > > Basically, as i see userspace printing do something different. It puts > > > N_FIFO_BYTES > > > and exits, next, when FIFO will be freed - interrupt will be > generated, and > > > other characters will be put into UART FIFO. > > > Can we do something similar for kernel printing? i.e. do not busyloop > > > sending char > > > after char, but put N_FIFO chars and flush other in interrupt. When > panic > > > will occur > > > we can do busyloop printing again. Is it reliable? Suppose we have > several > > > cores. > > > Thank you. > > > > > What about trying this patch, > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/kernel/printk/printk.c?id=5874af2003b1053128d655710140e3187226 > > > > Its not changing console printing through UART to interrupt mode. But > > minimizes the time interrupts being disabled on printk(). > > > > Thanks, > > Arun > > > > > > > > > > > > -- > > > Alexander > > > > > > ___ > > > Kernelnewbies mailing list > > > Kernelnewbies@kernelnewbies.org > > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > > > -- > Alexander > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Delegating printk work to UART interrupt
Hi Arun KS, Actually, i already saw this one and something similar were tested. I just trying to figure out the reasons why generic kernel layer (console_unlock) implemented in such way: i.e. why it accounts on immediate busyloop printing? Is it reliable to defer such printing to UART interrupts? Thank you. On Mon, 20 Jul 2015 09:34:16 +0530 Arun KS wrote: > Hello Alexander, > > On Sat, Jul 18, 2015 at 11:23 AM, Alexander wrote: > > > > > Hi! > > When i checked how kernel printing works, i mentioned that it takes > > messages > > from log_buffer in console_unlock and gives it to call_console_drivers -> > > ... > > -> some uart bsp function. Basically, as i see this BSP realization tries > > to flush all message chars in busyloop ... so it waits until FIFO_NOT_FULL > > bit will > > be dropped by UART and it will be able to push the next byte. > > Basically, as i see userspace printing do something different. It puts > > N_FIFO_BYTES > > and exits, next, when FIFO will be freed - interrupt will be generated, and > > other characters will be put into UART FIFO. > > Can we do something similar for kernel printing? i.e. do not busyloop > > sending char > > after char, but put N_FIFO chars and flush other in interrupt. When panic > > will occur > > we can do busyloop printing again. Is it reliable? Suppose we have several > > cores. > > Thank you. > > > What about trying this patch, > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/kernel/printk/printk.c?id=5874af2003b1053128d655710140e3187226 > > Its not changing console printing through UART to interrupt mode. But > minimizes the time interrupts being disabled on printk(). > > Thanks, > Arun > > > > > > > -- > > Alexander > > > > ___ > > Kernelnewbies mailing list > > Kernelnewbies@kernelnewbies.org > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -- Alexander ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Delegating printk work to UART interrupt
Hello Alexander, On Sat, Jul 18, 2015 at 11:23 AM, Alexander wrote: > > Hi! > When i checked how kernel printing works, i mentioned that it takes > messages > from log_buffer in console_unlock and gives it to call_console_drivers -> > ... > -> some uart bsp function. Basically, as i see this BSP realization tries > to flush all message chars in busyloop ... so it waits until FIFO_NOT_FULL > bit will > be dropped by UART and it will be able to push the next byte. > Basically, as i see userspace printing do something different. It puts > N_FIFO_BYTES > and exits, next, when FIFO will be freed - interrupt will be generated, and > other characters will be put into UART FIFO. > Can we do something similar for kernel printing? i.e. do not busyloop > sending char > after char, but put N_FIFO chars and flush other in interrupt. When panic > will occur > we can do busyloop printing again. Is it reliable? Suppose we have several > cores. > Thank you. > What about trying this patch, https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/kernel/printk/printk.c?id=5874af2003b1053128d655710140e3187226 Its not changing console printing through UART to interrupt mode. But minimizes the time interrupts being disabled on printk(). Thanks, Arun > > -- > Alexander > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Delegating printk work to UART interrupt
Hi! When i checked how kernel printing works, i mentioned that it takes messages from log_buffer in console_unlock and gives it to call_console_drivers -> ... -> some uart bsp function. Basically, as i see this BSP realization tries to flush all message chars in busyloop ... so it waits until FIFO_NOT_FULL bit will be dropped by UART and it will be able to push the next byte. Basically, as i see userspace printing do something different. It puts N_FIFO_BYTES and exits, next, when FIFO will be freed - interrupt will be generated, and other characters will be put into UART FIFO. Can we do something similar for kernel printing? i.e. do not busyloop sending char after char, but put N_FIFO chars and flush other in interrupt. When panic will occur we can do busyloop printing again. Is it reliable? Suppose we have several cores. Thank you. -- Alexander ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
