On Fri, Feb 01, 2019 at 02:03:46PM -0800, Andrew Morton wrote:
> On Thu, 31 Jan 2019 18:43:10 -0800 Matthew Wilcox wrote:
>
> > On Fri, Feb 01, 2019 at 11:42:42AM +1100, Tobin C. Harding wrote:
> > > Currently when displaying /proc/slabinfo if any cache names are too long
> > > then the output
On Thu, Jan 31, 2019 at 06:43:10PM -0800, Matthew Wilcox wrote:
> On Fri, Feb 01, 2019 at 11:42:42AM +1100, Tobin C. Harding wrote:
> > Currently when displaying /proc/slabinfo if any cache names are too long
> > then the output columns are not aligned. We could do something fancy to
> > get the
On Fri, Feb 01, 2019 at 07:27:24PM -0800, Joe Perches wrote:
> On Fri, 2019-02-01 at 11:42 +1100, Tobin C. Harding wrote:
> > Increase the width of the first column (cache name) in the output of
> > /proc/slabinfo from 17 to 30 characters.
>
> Do you care if this breaks any parsing of
Hi,
On 01/02/2019 4.34, Christopher Lameter wrote:
On Fri, 1 Feb 2019, Tobin C. Harding wrote:
Currently when displaying /proc/slabinfo if any cache names are too long
then the output columns are not aligned. We could do something fancy to
get the maximum length of any cache name in the
On Fri, 2019-02-01 at 11:42 +1100, Tobin C. Harding wrote:
> Increase the width of the first column (cache name) in the output of
> /proc/slabinfo from 17 to 30 characters.
Do you care if this breaks any parsing of /proc/slabinfo?
I don't but someone might.
On Thu, 31 Jan 2019 18:43:10 -0800 Matthew Wilcox wrote:
> On Fri, Feb 01, 2019 at 11:42:42AM +1100, Tobin C. Harding wrote:
> > Currently when displaying /proc/slabinfo if any cache names are too long
> > then the output columns are not aligned. We could do something fancy to
> > get the
On Thu, Jan 31, 2019 at 06:43:10PM -0800, Matthew Wilcox wrote:
> On Fri, Feb 01, 2019 at 11:42:42AM +1100, Tobin C. Harding wrote:
> > Currently when displaying /proc/slabinfo if any cache names are too long
> > then the output columns are not aligned. We could do something fancy to
> > get the
On Thu, Jan 31, 2019 at 05:13:06PM -0800, Andrew Morton wrote:
> On Fri, 1 Feb 2019 11:58:38 +1100 "Tobin C. Harding" wrote:
>
> > On Fri, Feb 01, 2019 at 11:42:42AM +1100, Tobin C. Harding wrote:
> > [snip]
> >
> > This applies on top of Linus' tree
> >
> > commit e74c98ca2d6a ('gfs2:
On Fri, Feb 01, 2019 at 11:42:42AM +1100, Tobin C. Harding wrote:
> Currently when displaying /proc/slabinfo if any cache names are too long
> then the output columns are not aligned. We could do something fancy to
> get the maximum length of any cache name in the system or we could just
>
On Fri, 1 Feb 2019, Tobin C. Harding wrote:
> Currently when displaying /proc/slabinfo if any cache names are too long
> then the output columns are not aligned. We could do something fancy to
> get the maximum length of any cache name in the system or we could just
> increase the hardcoded
On Fri, 1 Feb 2019 11:58:38 +1100 "Tobin C. Harding" wrote:
> On Fri, Feb 01, 2019 at 11:42:42AM +1100, Tobin C. Harding wrote:
> [snip]
>
> This applies on top of Linus' tree
>
> commit e74c98ca2d6a ('gfs2: Revert "Fix loop in gfs2_rbm_find"')
>
> For this patch I doubt very much that
On Fri, Feb 01, 2019 at 11:42:42AM +1100, Tobin C. Harding wrote:
[snip]
This applies on top of Linus' tree
commit e74c98ca2d6a ('gfs2: Revert "Fix loop in gfs2_rbm_find"')
For this patch I doubt very much that it matters but for the record I
can't find mention in MAINTAINERS which tree
Currently when displaying /proc/slabinfo if any cache names are too long
then the output columns are not aligned. We could do something fancy to
get the maximum length of any cache name in the system or we could just
increase the hardcoded width. Currently it is 17 characters. Monitors
are wide
13 matches
Mail list logo
