[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#679094: linux-image-3.4-trunk-amd64: 3.2, 3.3 and 3.4 debian kernels lack latencytop support



On Wed, 2012-06-27 at 10:34 +0200, Martin Steigerwald wrote:
> Am Mittwoch, 27. Juni 2012 schrieb Ben Hutchings:
> > On Tue, 2012-06-26 at 12:46 +0200, Martin Steigerwald wrote:
> > [...]
> > 
> > > The current Debian kernels all lack latencytop support:
> > [...]
> > 
> > > Please consider activating this support again.
> > 
> > What do you mean, 'again'?
> 
> I thought this was once working out of the box, but maybe that was at a time 
> where I compiled my own kernels and had it enabled.

I think it must have been, as there is no record of this in the
changelog.

> > > Otherwise someone who wants to use latencytop needs to recompile the
> > > kernel which greatly reduces the usefulness of the latencytop package.
> > 
> > This costs 1680 or 3360 bytes of non-paged memory for every thread in
> > the system (depending on word size), even if the feature is never
> > actually used.  On my laptop, for example, this would be about a
> > megabyte.  I really don't think this is a good idea.
> 
> I found out that it will need the framepointer stuff which makes the kernel 
> slightly larger and slower only after writing the bug report.

I didn't even get as far as that, but yes.  This would particularly hurt
i386 which is short of registers.

> While I do not care that much about the megabyte given current memory sizes, I 
> am concerned about the "slightly slower". And then its declared as kernel 
> hacking feature in the configuration anyway. And for older / embedded machines 
> 1 MiB might be much.
> 
> So I can understand your reasoning. Feel free to close as won't fix or 
> "dependent / waiting for upstream fix" if thats possible.
> 
> > It is probably possible to change the way the latency records are kept
> > so that this memory is allocated only when needed, but I'm unlikely to
> > find the time to do that.
> 
> Care to elaborate on that one a bit. I am willing to open a upstream bug 
> report about that and include your idea and a reference to this debian bug 
> report.

The definition of struct task_struct includes:

#ifdef CONFIG_LATENCYTOP
	int latency_record_count;
	struct latency_record latency_record[LT_SAVECOUNT];
#endif

I was thinking that latency_record could be changed to a pointer, and
the array allocated only when latency tracing is turned on.  This should
be easy to do for new tasks; harder if existing tasks should also be
traced.

Ben.

-- 
Ben Hutchings
Lowery's Law:
             If it jams, force it. If it breaks, it needed replacing anyway.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: