lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150807143012.GG30785@dhcp22.suse.cz>
Date:	Fri, 7 Aug 2015 16:30:12 +0200
From:	Michal Hocko <mhocko@...nel.org>
To:	PINTU KUMAR <pintu.k@...sung.com>
Cc:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, minchan@...nel.org, dave@...olabs.net,
	koct9i@...il.com, mgorman@...e.de, vbabka@...e.cz,
	js1304@...il.com, hannes@...xchg.org, alexander.h.duyck@...hat.com,
	sasha.levin@...cle.com, cl@...ux.com, fengguang.wu@...el.com,
	cpgs@...sung.com, pintu_agarwal@...oo.com, pintu.k@...look.com,
	vishnu.ps@...sung.com, rohit.kr@...sung.com
Subject: Re: [PATCH 1/1] mm: vmstat: introducing vm counter for slowpath

On Fri 07-08-15 18:16:47, PINTU KUMAR wrote:
[...]
> > On Fri 07-08-15 12:38:54, Pintu Kumar wrote:
> > > This patch add new counter slowpath_entered in /proc/vmstat to track
> > > how many times the system entered into slowpath after first allocation
> > > attempt is failed.
> > 
> > This is too lowlevel to be exported in the regular user visible interface IMO.
> > 
> I think its ok because I think this interface is for lowlevel debugging itself.

Yes but this might change in future implementations where the counter
might be misleading or even lacking any meaning. This is a user visible
interface which has to be maintained practically for ever. We have made
those mistakes in the past...

[...]
> This information is good for kernel developers.

Then make it a trace point and you can dump even more information. E.g.
timestamps, gfp_mask, order...

[...]

> Regarding trace points, I am not sure if we can attach counter to it.

You do not need to have a counter. You just watch for the tracepoint
while debugging your particular problem.

> Also trace may have more over-head 

Tracepoints should be close to 0 overhead when disabled and certainly
not a performance killer during the debugging session.

> and requires additional configs to be enabled to debug.

This is to be expected for the debugging sessions. And I am pretty
sure that the static event tracepoints do not require anything really
excessive.

> Mostly these configs will not be enabled by default (at least in embedded, low
> memory device).

Are you sure? I thought that CONFIG_TRACING should be sufficient for
EVENT_TRACING but I am not familiar with this too deeply...
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ