linux-kernel - Re: [PATCH] sched: Provide iowait counters

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: <alpine.DEB.2.00.0907201540550.26208@gandalf.stny.rr.com>
Date:	Mon, 20 Jul 2009 15:42:10 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
	Frédéric Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH] sched: Provide iowait counters


On Mon, 20 Jul 2009, Peter Zijlstra wrote:
> 
> > +++ b/kernel/sched_fair.c
> > @@ -633,6 +633,11 @@ static void enqueue_sleeper(struct cfs_rq *cfs_rq, struct sched_entity *se)
> >   		se->block_start = 0;
> >   		se->sum_sleep_runtime += delta;
> > 
> > +		if (tsk->in_iowait) {
> > +			se->iowait_sum += delta;
> > +			se->iowait_count++;
> > +		}
> > +
> >   		/*
> >   		 * Blocking time is in units of nanosecs, so shift by 20 to
> >   		 * get a milliseconds-range estimation of the amount of
> 
> It might be nice to put a tracepoint there as well, now if there was a
> way to specify perf counter attributes in the TRACE_EVENT() magic so
> that we can feed stuff into perf_tpcounter_event().
> 
> TP_perf_addr()  -- defaults to 0 when not specified
> TP_perf_count() -- defaults to 1 when not specified.
> 
> Steve, Frederic, is there any way to make that happen?
> 
> Failing that we could put an actual swcounter in there I suppose.
> 
> That way we could profile applications based on IO-wait, which would be
> cool.

How would you imagine an interface for this? Could you come up with 
something that you would like to see, and then I could see if we could 
implement it. 

How would the TRACE_EVENT look exactly? Would there be anything different 
in the trace point location itself?

Thanks,

-- Steve

--
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/