From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752674AbdCQCFZ (ORCPT ); Thu, 16 Mar 2017 22:05:25 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:34468 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751539AbdCQCFX (ORCPT ); Thu, 16 Mar 2017 22:05:23 -0400 Date: Fri, 17 Mar 2017 10:56:00 +0900 From: Sergey Senozhatsky To: Joe Perches Cc: Sergey Senozhatsky , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 1/3] mm: page_alloc: Reduce object size by neatening printks Message-ID: <20170317015600.GA426@jagdpanzerIV.localdomain> References: <880b3172b67d806082284d80945e4a231a5574bb.1489628459.git.joe@perches.com> <20170316113056.GG464@jagdpanzerIV.localdomain> <1489689476.13953.3.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1489689476.13953.3.camel@perches.com> User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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)); > > > + printk("active_anon:%lu inactive_anon:%lu isolated_anon:%lu\n", > > > + global_node_page_state(NR_ACTIVE_ANON), > > > + global_node_page_state(NR_INACTIVE_ANON), > > > + global_node_page_state(NR_ISOLATED_ANON)); > > > + printk("active_file:%lu inactive_file:%lu isolated_file:%lu\n", > > > + global_node_page_state(NR_ACTIVE_FILE), > > > + global_node_page_state(NR_INACTIVE_FILE), > > > + global_node_page_state(NR_ISOLATED_FILE)); > > > + printk("unevictable:%lu dirty:%lu writeback:%lu unstable:%lu\n", > > > + 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)); > > > + printk("slab_reclaimable:%lu slab_unreclaimable:%lu\n", > > > + global_page_state(NR_SLAB_RECLAIMABLE), > > > + global_page_state(NR_SLAB_UNRECLAIMABLE)); > > > + printk("mapped:%lu shmem:%lu pagetables:%lu bounce:%lu\n", > > > + global_node_page_state(NR_FILE_MAPPED), > > > + global_node_page_state(NR_SHMEM), > > > + global_page_state(NR_PAGETABLE), > > > + global_page_state(NR_BOUNCE)); > > > + printk("free:%lu free_pcp:%lu free_cma:%lu\n", > > > + 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". -ss