(adding Petr and Steven to cc's)
On Fri, 2017-03-17 at 10:56 +0900, Sergey Senozhatsky wrote:
> On (03/16/17 11:37), Joe Perches wrote:
> > On Thu, 2017-03-16 at 20:30 +0900, Sergey Senozhatsky wrote:
> > > On (03/15/17 18:43), Joe Perches wrote:
> > > [..]
> > > > - printk("active_anon:%lu inactive_anon:%lu isolated_anon:%lu\n"
> > > > - " active_file:%lu inactive_file:%lu isolated_file:%lu\n"
> > > > - " unevictable:%lu dirty:%lu writeback:%lu unstable:%lu\n"
> > > > - " slab_reclaimable:%lu slab_unreclaimable:%lu\n"
> > > > - " mapped:%lu shmem:%lu pagetables:%lu bounce:%lu\n"
> > > > - " free:%lu free_pcp:%lu free_cma:%lu\n",
> > > > - global_node_page_state(NR_ACTIVE_ANON),
> > > > - global_node_page_state(NR_INACTIVE_ANON),
> > > > - global_node_page_state(NR_ISOLATED_ANON),
> > > > - global_node_page_state(NR_ACTIVE_FILE),
> > > > - global_node_page_state(NR_INACTIVE_FILE),
> > > > - global_node_page_state(NR_ISOLATED_FILE),
> > > > - global_node_page_state(NR_UNEVICTABLE),
> > > > - global_node_page_state(NR_FILE_DIRTY),
> > > > - global_node_page_state(NR_WRITEBACK),
> > > > - global_node_page_state(NR_UNSTABLE_NFS),
> > > > - global_page_state(NR_SLAB_RECLAIMABLE),
> > > > - global_page_state(NR_SLAB_UNRECLAIMABLE),
> > > > - global_node_page_state(NR_FILE_MAPPED),
> > > > - global_node_page_state(NR_SHMEM),
> > > > - global_page_state(NR_PAGETABLE),
> > > > - global_page_state(NR_BOUNCE),
> > > > - global_page_state(NR_FREE_PAGES),
> > > > - free_pcp,
> > > > - global_page_state(NR_FREE_CMA_PAGES));
[]
> > > > a side note:
> > >
> > > this can make it harder to read, in _the worst case_. one printk()
> > > guaranteed that we would see a single line in the serial log/etc.
> > > the sort of a problem with multiple printks is that printks coming
> > > from other CPUs will split that "previously single" line.
> >
> > Not true. Note the multiple \n uses in the original code.
>
> one printk call ends up in logbuf as a single entry and, thus, we print
> it to the serial console in one shot (what is the correct english word
> to use here?). multiple printks result in multiple logbuf entries, and
> printks from other CPUs can mix in.
>
> so the difference is:
>
>
> CPU0 CPU1
> printk(foo\n)
> printk(..isolated_anon\n...isolated_file\n...)
> printk(bar\n)
>
> vs
>
> CPU0 CPU1
> printk(..isolated_anon\n)
> printk(foo\n)
> printk(...isolated_file\n)
> printk(bar\n)
> printk(...\n)
>
> not the same thing.
>
> and the slower the serial console is the more messages potentially
> can appear between "..isolated_anon\n" and "...isolated_file\n".
Right. For the definition of "single line", meaning "contiguous
block" and not single line.
Perhaps there would be some value in having a generic mechanism
for the dump_stack use of "atomic_t dump_lock", where a thread
can grab exclusive use of the printk subsystem for a short period
to keep messages from being interleaved by other processes.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
