public inbox for cgroups@vger.kernel.org
 help / color / mirror / Atom feed
From: "Liam R. Howlett" <Liam.Howlett@Oracle.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Kent Overstreet <kent.overstreet@linux.dev>,
	Suren Baghdasaryan <surenb@google.com>,
	akpm@linux-foundation.org, mhocko@suse.com, vbabka@suse.cz,
	hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de,
	willy@infradead.org, corbet@lwn.net, void@manifault.com,
	peterz@infradead.org, juri.lelli@redhat.com,
	ldufour@linux.ibm.com, catalin.marinas@arm.com, will@kernel.org,
	arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com,
	dave.hansen@linux.intel.com, x86@kernel.org, peterx@redhat.com,
	david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org,
	masahiroy@kernel.org, nathan@kernel.org, dennis@kernel.org,
	tj@kernel.org, muchun.song@linux.dev, rppt@kernel.org,
	paulmck@kernel.org, pasha.tatashin@soleen.com,
	yosryahmed@google.com, yuzhao@google.com, dhowells@redhat.com,
	hughd@google.com
Subject: Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output
Date: Mon, 1 May 2023 17:33:49 -0400	[thread overview]
Message-ID: <20230501213349.bvbf6i72eepcd56m@revolver> (raw)
In-Reply-To: <CAHp75VeJ_a6j3uweLN5-woSQUtN5u36c2gkoiXhnJa1HXJdoyQ@mail.gmail.com>

* Andy Shevchenko <andy.shevchenko@gmail.com> [230501 15:57]:
> On Mon, May 1, 2023 at 10:36 PM Kent Overstreet
> <kent.overstreet@linux.dev> wrote:
> >
> > On Mon, May 01, 2023 at 11:13:15AM -0700, Davidlohr Bueso wrote:
> > > On Mon, 01 May 2023, Suren Baghdasaryan wrote:
> > >
> > > > From: Kent Overstreet <kent.overstreet@linux.dev>
> > > >
> > > > Previously, string_get_size() outputted a space between the number and
> > > > the units, i.e.
> > > >  9.88 MiB
> > > >
> > > > This changes it to
> > > >  9.88MiB
> > > >
> > > > which allows it to be parsed correctly by the 'sort -h' command.
> 
> But why do we need that? What's the use case?
> 
> > > Wouldn't this break users that already parse it the current way?
> >
> > It's not impossible - but it's not used in very many places and we
> > wouldn't be printing in human-readable units if it was meant to be
> > parsed - it's mainly used for debug output currently.
> >
> > If someone raises a specific objection we'll do something different,
> > otherwise I think standardizing on what userspace tooling already parses
> > is a good idea.
> 
> Yes, I NAK this on the basis of
> https://english.stackexchange.com/a/2911/153144

This fixes the output to be better aligned with:
the output of ls -sh
the input expected by find -size

Are there counter-examples of commands that follow the SI Brochure?

Thanks,
Liam

  parent reply	other threads:[~2023-05-01 21:33 UTC|newest]

Thread overview: 160+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-01 16:54 [PATCH 00/40] Memory allocation profiling Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output Suren Baghdasaryan
     [not found]   ` <20230501165450.15352-2-surenb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2023-05-01 18:13     ` Davidlohr Bueso
2023-05-01 19:35       ` Kent Overstreet
     [not found]       ` <ZFAUj+Q+hP7cWs4w@moria.home.lan>
2023-05-01 19:57         ` Andy Shevchenko
2023-05-01 21:16           ` Kent Overstreet
2023-05-01 21:33           ` Liam R. Howlett [this message]
2023-05-02  0:11             ` Kent Overstreet
2023-05-02  0:53           ` Kent Overstreet
     [not found]         ` <ZFAUj+Q+hP7cWs4w-jC9Py7bek1znysI04z7BkA@public.gmane.org>
2023-05-02  2:22           ` James Bottomley
     [not found]         ` <b6b472b65b76e95bb4c7fc7eac1ee296fdbb64fd.camel@HansenPartnership.com>
     [not found]           ` <b6b472b65b76e95bb4c7fc7eac1ee296fdbb64fd.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2023-05-02  3:17             ` Kent Overstreet
     [not found]               ` <ZFCA2FF+9MI8LI5i-jC9Py7bek1znysI04z7BkA@public.gmane.org>
2023-05-02  5:33                 ` Andy Shevchenko
2023-05-02  6:21                   ` Kent Overstreet
2023-05-02 15:19                     ` Andy Shevchenko
2023-05-03  2:07                       ` Kent Overstreet
2023-05-03  6:30                         ` Andy Shevchenko
2023-05-03  7:12                           ` Kent Overstreet
2023-05-03  9:12                             ` Andy Shevchenko
     [not found]                               ` <CAHp75Vd_VMOh1zxJvr0KqhxYBXAU1X+Ax7YA1sJ0G_abEpn-Dg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-05-03  9:16                                 ` Kent Overstreet
2023-05-02 11:42               ` James Bottomley
2023-05-02 22:50                 ` Dave Chinner
2023-05-03  9:28                   ` Vlastimil Babka
2023-05-03  9:44                     ` Andy Shevchenko
     [not found]                   ` <20230502225016.GJ2155823-pA1nmv6sEBkOM8BvhN4Z8vybgvtCy99p@public.gmane.org>
2023-05-03 12:15                     ` James Bottomley
2023-05-02  7:55   ` Jani Nikula
2023-05-01 16:54 ` [PATCH 04/40] nodemask: Split out include/linux/nodemask_types.h Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 05/40] prandom: Remove unused include Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 06/40] lib/string.c: strsep_no_empty() Suren Baghdasaryan
2023-05-02 12:37   ` Petr Tesařík
2023-05-01 16:54 ` [PATCH 08/40] mm: introduce slabobj_ext to support slab object extensions Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 10/40] mm/slab: introduce SLAB_NO_OBJ_EXT to avoid obj_ext creation Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 11/40] mm: prevent slabobj_ext allocations for slabobj_ext and kmem_cache objects Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 12/40] slab: objext: introduce objext_flags as extension to page_memcg_data_flags Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 13/40] lib: code tagging framework Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 14/40] lib: code tagging module support Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 15/40] lib: prevent module unloading if memory is not freed Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 16/40] lib: code tagging query helper functions Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 17/40] lib: add allocation tagging support for memory allocation profiling Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 18/40] lib: introduce support for page allocation tagging Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 19/40] change alloc_pages name in dma_map_ops to avoid name conflicts Suren Baghdasaryan
2023-05-02 15:50   ` Petr Tesařík
2023-05-02 18:38     ` Suren Baghdasaryan
2023-05-02 20:09       ` Petr Tesařík
2023-05-02 20:18         ` Kent Overstreet
2023-05-02 20:24         ` Suren Baghdasaryan
2023-05-02 20:39           ` Petr Tesařík
     [not found]             ` <20230502223915.6b38f8c4-TD/jYOLh/Qr2G+KSGY6Hrl+YFMdMcpeZ@public.gmane.org>
2023-05-02 20:41               ` Suren Baghdasaryan
     [not found]   ` <20230501165450.15352-20-surenb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2023-05-03 16:25     ` Steven Rostedt
2023-05-03 18:03       ` Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 22/40] mm: create new codetag references during page splitting Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 24/40] mm/slab: add allocation accounting into slab allocation and free paths Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 25/40] mm/slab: enable slab allocation tagging for kmalloc and friends Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 26/40] mm/slub: Mark slab_free_freelist_hook() __always_inline Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 27/40] mempool: Hook up to memory allocation profiling Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 29/40] mm: percpu: Introduce pcpuobj_ext Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 31/40] mm: percpu: enable per-cpu allocation tagging Suren Baghdasaryan
     [not found] ` <20230501165450.15352-1-surenb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2023-05-01 16:54   ` [PATCH 02/40] scripts/kallysms: Always include __start and __stop symbols Suren Baghdasaryan
2023-05-01 16:54   ` [PATCH 03/40] fs: Convert alloc_inode_sb() to a macro Suren Baghdasaryan
2023-05-02 12:35     ` Petr Tesařík
     [not found]       ` <20230502143530.1586e287-TD/jYOLh/Qr2G+KSGY6Hrl+YFMdMcpeZ@public.gmane.org>
2023-05-02 19:57         ` Kent Overstreet
2023-05-02 20:20           ` Petr Tesařík
2023-05-01 16:54   ` [PATCH 07/40] Lazy percpu counters Suren Baghdasaryan
2023-05-01 19:17     ` Randy Dunlap
2023-05-01 16:54   ` [PATCH 09/40] mm: introduce __GFP_NO_OBJ_EXT flag to selectively prevent slabobj_ext creation Suren Baghdasaryan
     [not found]     ` <20230501165450.15352-10-surenb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2023-05-02 12:50       ` Petr Tesařík
2023-05-02 18:33         ` Suren Baghdasaryan
2023-05-01 16:54   ` [PATCH 20/40] mm: enable page allocation tagging Suren Baghdasaryan
2023-05-01 16:54   ` [PATCH 21/40] mm/page_ext: enable early_page_ext when CONFIG_MEM_ALLOC_PROFILING_DEBUG=y Suren Baghdasaryan
2023-05-01 16:54   ` [PATCH 23/40] lib: add codetag reference into slabobj_ext Suren Baghdasaryan
2023-05-01 16:54   ` [PATCH 28/40] timekeeping: Fix a circular include dependency Suren Baghdasaryan
     [not found]     ` <20230501165450.15352-29-surenb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2023-05-02 15:50       ` Thomas Gleixner
2023-05-01 16:54   ` [PATCH 30/40] mm: percpu: Add codetag reference into pcpuobj_ext Suren Baghdasaryan
2023-05-01 16:54   ` [PATCH 32/40] arm64: Fix circular header dependency Suren Baghdasaryan
2023-05-01 16:54   ` [PATCH 33/40] move stack capture functionality into a separate function for reuse Suren Baghdasaryan
2023-05-01 17:47   ` [PATCH 00/40] Memory allocation profiling Roman Gushchin
2023-05-01 18:08     ` Suren Baghdasaryan
2023-05-01 18:14       ` Roman Gushchin
2023-05-01 19:37         ` Kent Overstreet
     [not found]           ` <ZFAVFlrRtpVgxJ0q-jC9Py7bek1znysI04z7BkA@public.gmane.org>
2023-05-01 21:18             ` Roman Gushchin
2023-05-01 16:54 ` [PATCH 34/40] lib: code tagging context capture support Suren Baghdasaryan
2023-05-03  7:35   ` Michal Hocko
2023-05-03 15:18     ` Suren Baghdasaryan
2023-05-03 15:26       ` Dave Hansen
2023-05-03 19:45         ` Suren Baghdasaryan
     [not found]       ` <CAJuCfpHrZ4kWYFPvA3W9J+CmNMuOtGa_ZMXE9fOmKsPQeNt2tg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-05-04  8:04         ` Michal Hocko
2023-05-04 14:31           ` Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 35/40] lib: implement context capture support for tagged allocations Suren Baghdasaryan
2023-05-03  7:39   ` Michal Hocko
     [not found]     ` <ZFIPmnrSIdJ5yusM-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2023-05-03 15:24       ` Suren Baghdasaryan
2023-05-04  8:09         ` Michal Hocko
2023-05-04 16:22           ` Suren Baghdasaryan
2023-05-05  8:40             ` Michal Hocko
     [not found]               ` <ZFTA8xVzxWc345Ug-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2023-05-05 18:10                 ` Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 36/40] lib: add memory allocations report in show_mem() Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 37/40] codetag: debug: skip objext checking when it's for objext itself Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 38/40] codetag: debug: mark codetags for reserved pages as empty Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 39/40] codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations Suren Baghdasaryan
2023-05-01 16:54 ` [PATCH 40/40] MAINTAINERS: Add entries for code tagging and memory allocation profiling Suren Baghdasaryan
2023-05-03  7:25 ` [PATCH 00/40] Memory " Michal Hocko
2023-05-03  7:34   ` Kent Overstreet
     [not found]     ` <ZFIOfb6/jHwLqg6M-jC9Py7bek1znysI04z7BkA@public.gmane.org>
2023-05-03  7:51       ` Michal Hocko
     [not found]         ` <ZFISlX+mSx4QJDK6-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2023-05-03  8:05           ` Kent Overstreet
2023-05-03 13:21             ` Steven Rostedt
     [not found]             ` <ZFIVtB8JyKk0ddA5-jC9Py7bek1znysI04z7BkA@public.gmane.org>
2023-05-03 16:35               ` Tejun Heo
     [not found]                 ` <ZFKNZZwC8EUbOLMv-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2023-05-03 17:42                   ` Suren Baghdasaryan
2023-05-03 18:06                     ` Tejun Heo
2023-05-03 17:44                   ` Kent Overstreet
2023-05-03 17:51                   ` Kent Overstreet
2023-05-03 18:24                     ` Tejun Heo
2023-05-03 18:07                 ` Johannes Weiner
     [not found]                   ` <20230503180726.GA196054-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2023-05-03 18:19                     ` Tejun Heo
     [not found]                       ` <ZFKlrP7nLn93iIRf-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2023-05-03 18:40                         ` Tejun Heo
2023-05-03 18:56                           ` Kent Overstreet
     [not found]                             ` <ZFKubD/lq7oB4svV-jC9Py7bek1znysI04z7BkA@public.gmane.org>
2023-05-03 18:58                               ` Tejun Heo
2023-05-03 19:09                                 ` Tejun Heo
     [not found]                                   ` <ZFKxcfqkUQ60zBB_-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2023-05-03 19:41                                     ` Suren Baghdasaryan
     [not found]                                       ` <CAJuCfpEPkCJZO2svT-GfmpJ+V-jSLyFDKM_atnqPVRBKtzgtnQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-05-03 19:48                                         ` Tejun Heo
2023-05-03 20:00                                           ` Tejun Heo
     [not found]                                             ` <ZFK9XMSzOBxIFOHm-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2023-05-03 20:14                                               ` Suren Baghdasaryan
2023-05-04  2:25                                                 ` Tejun Heo
2023-05-04  3:33                                                   ` Kent Overstreet
     [not found]                                                   ` <ZFMXmj9ZhSe5wyaS-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2023-05-04  3:33                                                     ` Suren Baghdasaryan
2023-05-04  8:00                                                 ` Petr Tesařík
     [not found]                                           ` <ZFK6pwOelIlhV8Bm-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2023-05-03 20:08                                             ` Suren Baghdasaryan
2023-05-03 20:11                                               ` Johannes Weiner
2023-05-04  2:16                                               ` Tejun Heo
2023-05-03 20:04                 ` Andrey Ryabinin
2023-05-03  9:50         ` Petr Tesařík
     [not found]           ` <20230503115051.30b8a97f-TD/jYOLh/Qr2G+KSGY6Hrl+YFMdMcpeZ@public.gmane.org>
2023-05-03  9:54             ` Kent Overstreet
     [not found]               ` <ZFIvY5p1UAXxHw9s-jC9Py7bek1znysI04z7BkA@public.gmane.org>
2023-05-03 10:24                 ` Petr Tesařík
2023-05-03  9:57           ` Kent Overstreet
2023-05-03 10:26             ` Petr Tesařík
2023-05-03 15:30               ` Kent Overstreet
2023-05-03 12:33             ` James Bottomley
     [not found]               ` <25a1ea786712df5111d7d1db42490624ac63651e.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2023-05-03 14:31                 ` Suren Baghdasaryan
2023-05-03 15:28               ` Kent Overstreet
2023-05-03 15:37                 ` Lorenzo Stoakes
2023-05-03 16:03                   ` Kent Overstreet
2023-05-03 15:49                 ` James Bottomley
2023-05-03 15:09   ` Suren Baghdasaryan
2023-05-03 16:28     ` Steven Rostedt
     [not found]       ` <20230503122839.0d9934c5-f9ZlEuEWxVcJvu8Pb33WZ0EMvNT87kid@public.gmane.org>
2023-05-03 17:40         ` Suren Baghdasaryan
2023-05-03 18:03           ` Steven Rostedt
2023-05-03 18:07             ` Suren Baghdasaryan
2023-05-03 18:12             ` Kent Overstreet
2023-05-04  9:07     ` Michal Hocko
2023-05-04 15:08       ` Suren Baghdasaryan
     [not found]         ` <CAJuCfpEkV_+pAjxyEpMqY+x7buZhSpj5qDF6KubsS=ObrQKUZg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-05-07 10:27           ` Michal Hocko
2023-05-07 17:01             ` Kent Overstreet
     [not found]       ` <ZFN1yswCd9wRgYPR-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2023-05-07 17:20         ` Kent Overstreet
2023-05-07 20:55           ` Steven Rostedt
2023-05-07 21:53             ` Kent Overstreet
2023-05-07 22:09               ` Steven Rostedt
     [not found]                 ` <20230507180911.09d328c8-tvvo3QnZDcrq6bvjpv6Lkf3PFXHtQ0wO@public.gmane.org>
2023-05-07 22:17                   ` Kent Overstreet
2023-05-08 15:52           ` Petr Tesařík
2023-05-08 15:57             ` Kent Overstreet
2023-05-08 16:09               ` Petr Tesařík
     [not found]                 ` <20230508180913.6a018b21-TD/jYOLh/Qr2G+KSGY6Hrl+YFMdMcpeZ@public.gmane.org>
2023-05-08 16:28                   ` Kent Overstreet
     [not found]                     ` <ZFkjRBCExpXfI+O5-jC9Py7bek1znysI04z7BkA@public.gmane.org>
2023-05-08 18:59                       ` Petr Tesařík
     [not found]                         ` <20230508205939.0b5b485c-TD/jYOLh/Qr2G+KSGY6Hrl+YFMdMcpeZ@public.gmane.org>
2023-05-08 20:48                           ` Kent Overstreet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230501213349.bvbf6i72eepcd56m@revolver \
    --to=liam.howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=axboe@kernel.dk \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=dennis@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=kent.overstreet@linux.dev \
    --cc=ldufour@linux.ibm.com \
    --cc=masahiroy@kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=muchun.song@linux.dev \
    --cc=nathan@kernel.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=paulmck@kernel.org \
    --cc=peterx@redhat.com \
    --cc=peterz@infradead.org \
    --cc=roman.gushchin@linux.dev \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=vbabka@suse.cz \
    --cc=void@manifault.com \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    --cc=yosryahmed@google.com \
    --cc=yuzhao@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox