linux-kernel - Re: [PATCH 1/2] mm: page_alloc.c: Add tracepoints for slowpath

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: <20160727142800.14bd93d0@gandalf.local.home>
Date:	Wed, 27 Jul 2016 14:28:00 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Rik van Riel <riel@...riel.com>
Cc:	Michal Hocko <mhocko@...nel.org>,
	Janani Ravichandran <janani.rvchndrn@...il.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, hannes@...pxchg.org,
	vdavydov@...tuozzo.com, vbabka@...e.cz,
	mgorman@...hsingularity.net, kirill.shutemov@...ux.intel.com,
	bywxiaobai@....com
Subject: Re: [PATCH 1/2] mm: page_alloc.c: Add tracepoints for slowpath

On Wed, 27 Jul 2016 14:16:22 -0400
Rik van Riel <riel@...riel.com> wrote:

> As for the function tracer, I wish I had known
> about that!

The kernel (and just the tracing infrastructure) is too big to know
everything that is there.

> 
> That looks like it should provide the info that
> Janani needs to write her memory allocation latency
> tracing script/tool.
> 
> As her Outreachy mentor, I should probably apologize
> for potentially having sent her down the wrong path
> with tracepoints, and I hope it has been an
> educational trip at least :)
> 

No, it was a perfect example of how we work, and I don't see this as a
wrong path. It's a good learning tool because that patch is exactly
what someone wanting to do a specific task will probably do as their
first attempt. There should be no shame in sending out a patch and have
feedback on another way to accomplish the same thing that doesn't
impact the system as much.

As stated above, the kernel is too big to know everything that needs to
be done. Thus, kernel development is really about trial and error. Send
out what works for you, and then take feedback from those that know
their system better than you to make your patch better.

That's how the workflow should happen on a daily basis. And is exactly
how I operate. There's lots of patches that I send out to other
maintainers that end up being something complete different because I
don't know their systems as well as they do.

-- Steve