All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tiago Simões Batista" <tiagosbatista@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Tiago Simões Batista" <tiagosbatista@gmail.com>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	"Matthew Garrett" <mjg59@srcf.ucam.org>,
	"Zhang Rui" <rui.zhang@intel.com>
Subject: Re: High latency on /sys/class/thermal
Date: Sun, 12 Apr 2009 17:03:20 +0100	[thread overview]
Message-ID: <20090412170320.52e374df@gmail.com> (raw)
In-Reply-To: <20090411231611.7c5f9b69@ua.pt>

On Sat, 11 Apr 2009 23:16:11 +0100
Tiago Simões Batista <tiagosbatista@gmail.com> wrote:

> Sorry about the noise, by brain was stopped when I sent the last mail,
> please ignore the From address, it is wrong!
> 
> On Sat, 11 Apr 2009 12:14:16 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > (cc linux-acpi)
> > 
> > On Sat, 11 Apr 2009 15:56:12 +0100 "Tiago Sim__es Batista"
> > <tiagosbatista@gmail.com> wrote:
> > 
> > > Hi all
> > > 
> > > Yesterday, I recompiled my kernel (git + tuxonice)
> > > v2.6.30-rc1-1002-gac91f91, there were a couple of issues, the main
> > > one is ilustrated bellow.
> > > 
> > > I am not familiar with the kernel code, but if you give me some
> > > pointers, I will be glad to investigate this further
> > > 
> > > $time cat /sys/class/thermal/thermal_zone0/temp 
> > > 34000
> > > 
> > > real	0m6.613s
> > > user	0m0.000s
> > > sys	0m0.001s
> > > 
> > 
> > Is this a regression?  Was 2.6.29 OK?
> > 
> > Thanks.
> 
> My last kernel was fine:
> 
> $ time cat /sys/class/thermal/thermal_zone0/temp 
> 48000
> 
> real	0m0.007s
> user	0m0.001s
> sys	0m0.007s
> 
> 
> I also forgot to add some information about my kernels...
> 
> The good one is 2.6.29 + tuxonice as it was the day after the 2.6.29
> kernel was released.
> 
> The bad one is a pull from linus tree on april the 9th plus tuxonice
> on the same day
> 
> from git (hope this helps):
> $ git describe v2.6.29-tiago2-ice
> v2.6.29-836-g00492ed
> $ git describe v2.6.30-rc1-tiago1-ice
> v2.6.30-rc1-1002-gac91f91
> 
> 
> If tuxonice is a suspect, I will be glad to remove it and recompile.
> If I have the time later this weekend, and nothing was found, I will
> try to bisect this.
> 

Here are some results from the bisect:
The metric I used to mark a revision as good/bad was
$ time for ((i =0; i < 100; i++)); do
      cat /sys/class/thermal/thermal_zone0/temp > /dev/null; 
  done

The bad ones take forever, i never even finished one bad run. The good
ones take about half a second.

When I checked out revisions v2.6.29-148-g33526a5 and
v2.6.29-159-g8a3f257, it took almost 2 secons to run the command, so I
think some of the latency my have been introduced around these. Yet, I
still marked them as good.

The resut was:
478c6a43fcbc6c11609f8cee7c7b57223907754f is first bad commit
witch is a merge. I am out of ideas...

I forgot to ask, am I the only one experiencing this? I am using a
TravelMate 4000 with the intel graphics chip, can anyone reproduce this?
If no one can reproduce this, I can still test a vanilla kernel to
remove TOI from the equation!

Tiago


Below is the bisect log:
$ git bisect log
git bisect start
# bad: [ac91f917d7ed7d1ebe14532ee137fcd759b4406d] Merge branch 'all' into all-tuxonice
git bisect bad ac91f917d7ed7d1ebe14532ee137fcd759b4406d
# good: [178a426510a901d9335f39d3391ae5e8628a36d1] Merge branch 'tuxonice' into all-tuxonice
git bisect good 178a426510a901d9335f39d3391ae5e8628a36d1
# good: [fdf9c9979a355916433262ea5e5e64bed5def86e] V4L/DVB (10465): dsbr100: Add few lost mutex locks.
git bisect good fdf9c9979a355916433262ea5e5e64bed5def86e
# good: [edbd606c4671fcd439164c8d63e896044d706156] Staging: wlan-ng: Replace WLAN_LOG_ERROR() with printk()
git bisect good edbd606c4671fcd439164c8d63e896044d706156
# good: [3516c6a8dc0b1153c611c4cf0dc4a51631f052bb] Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6
git bisect good 3516c6a8dc0b1153c611c4cf0dc4a51631f052bb
# bad: [3989203290fba6fdf6bc4825fbf6526e1bf17977] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
git bisect bad 3989203290fba6fdf6bc4825fbf6526e1bf17977
# bad: [d7ca6f8cdffa5765e486edb3dada9121fba8e6aa] Merge branch 'for-linus' of git://git.o-hand.com/linux-rpurdie-backlight
git bisect bad d7ca6f8cdffa5765e486edb3dada9121fba8e6aa
# good: [3b4dadf05d177289c279c50030c7c75e004952bb] Merge branch 'acpi_enforce_resources' into release
git bisect good 3b4dadf05d177289c279c50030c7c75e004952bb
# bad: [32fb6c17566ec66de87324a834c7776f40e35e78] Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
git bisect bad 32fb6c17566ec66de87324a834c7776f40e35e78
# good: [45e36c1666aa6c8b0c538abcf984b336184d8c3f] Merge git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6
git bisect good 45e36c1666aa6c8b0c538abcf984b336184d8c3f
# good: [33526a53600ac887d100e3c9b4be3637ac8ae3a5] Merge branch 'x2apic' into release
git bisect good 33526a53600ac887d100e3c9b4be3637ac8ae3a5
# good: [c542aadeb4700bc316834d862d52ba3d2664f13a] panasonic-laptop: Fix autoloading
git bisect good c542aadeb4700bc316834d862d52ba3d2664f13a
# bad: [478c6a43fcbc6c11609f8cee7c7b57223907754f] Merge branch 'linus' into release
git bisect bad 478c6a43fcbc6c11609f8cee7c7b57223907754f
# good: [15065531c1c5902775ae3ade24eb37d0e688353b] toshiba-acpi: remove MAINTAINERS entry
git bisect good 15065531c1c5902775ae3ade24eb37d0e688353b
# good: [8a3f257c704e02aee9869decd069a806b45be3f1] Merge branch 'misc' into release
git bisect good 8a3f257c704e02aee9869decd069a806b45be3f1
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: "Tiago Simões Batista" <tiagosbatista@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Tiago Simões Batista" <tiagosbatista@gmail.com>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	"Matthew Garrett" <mjg59@srcf.ucam.org>,
	"Zhang Rui" <rui.zhang@intel.com>
Subject: Re: High latency on /sys/class/thermal
Date: Sun, 12 Apr 2009 17:03:20 +0100	[thread overview]
Message-ID: <20090412170320.52e374df@gmail.com> (raw)
In-Reply-To: <20090411231611.7c5f9b69@ua.pt>

On Sat, 11 Apr 2009 23:16:11 +0100
Tiago Simões Batista <tiagosbatista@gmail.com> wrote:

> Sorry about the noise, by brain was stopped when I sent the last mail,
> please ignore the From address, it is wrong!
> 
> On Sat, 11 Apr 2009 12:14:16 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > (cc linux-acpi)
> > 
> > On Sat, 11 Apr 2009 15:56:12 +0100 "Tiago Sim__es Batista"
> > <tiagosbatista@gmail.com> wrote:
> > 
> > > Hi all
> > > 
> > > Yesterday, I recompiled my kernel (git + tuxonice)
> > > v2.6.30-rc1-1002-gac91f91, there were a couple of issues, the main
> > > one is ilustrated bellow.
> > > 
> > > I am not familiar with the kernel code, but if you give me some
> > > pointers, I will be glad to investigate this further
> > > 
> > > $time cat /sys/class/thermal/thermal_zone0/temp 
> > > 34000
> > > 
> > > real	0m6.613s
> > > user	0m0.000s
> > > sys	0m0.001s
> > > 
> > 
> > Is this a regression?  Was 2.6.29 OK?
> > 
> > Thanks.
> 
> My last kernel was fine:
> 
> $ time cat /sys/class/thermal/thermal_zone0/temp 
> 48000
> 
> real	0m0.007s
> user	0m0.001s
> sys	0m0.007s
> 
> 
> I also forgot to add some information about my kernels...
> 
> The good one is 2.6.29 + tuxonice as it was the day after the 2.6.29
> kernel was released.
> 
> The bad one is a pull from linus tree on april the 9th plus tuxonice
> on the same day
> 
> from git (hope this helps):
> $ git describe v2.6.29-tiago2-ice
> v2.6.29-836-g00492ed
> $ git describe v2.6.30-rc1-tiago1-ice
> v2.6.30-rc1-1002-gac91f91
> 
> 
> If tuxonice is a suspect, I will be glad to remove it and recompile.
> If I have the time later this weekend, and nothing was found, I will
> try to bisect this.
> 

Here are some results from the bisect:
The metric I used to mark a revision as good/bad was
$ time for ((i =0; i < 100; i++)); do
      cat /sys/class/thermal/thermal_zone0/temp > /dev/null; 
  done

The bad ones take forever, i never even finished one bad run. The good
ones take about half a second.

When I checked out revisions v2.6.29-148-g33526a5 and
v2.6.29-159-g8a3f257, it took almost 2 secons to run the command, so I
think some of the latency my have been introduced around these. Yet, I
still marked them as good.

The resut was:
478c6a43fcbc6c11609f8cee7c7b57223907754f is first bad commit
witch is a merge. I am out of ideas...

I forgot to ask, am I the only one experiencing this? I am using a
TravelMate 4000 with the intel graphics chip, can anyone reproduce this?
If no one can reproduce this, I can still test a vanilla kernel to
remove TOI from the equation!

Tiago


Below is the bisect log:
$ git bisect log
git bisect start
# bad: [ac91f917d7ed7d1ebe14532ee137fcd759b4406d] Merge branch 'all' into all-tuxonice
git bisect bad ac91f917d7ed7d1ebe14532ee137fcd759b4406d
# good: [178a426510a901d9335f39d3391ae5e8628a36d1] Merge branch 'tuxonice' into all-tuxonice
git bisect good 178a426510a901d9335f39d3391ae5e8628a36d1
# good: [fdf9c9979a355916433262ea5e5e64bed5def86e] V4L/DVB (10465): dsbr100: Add few lost mutex locks.
git bisect good fdf9c9979a355916433262ea5e5e64bed5def86e
# good: [edbd606c4671fcd439164c8d63e896044d706156] Staging: wlan-ng: Replace WLAN_LOG_ERROR() with printk()
git bisect good edbd606c4671fcd439164c8d63e896044d706156
# good: [3516c6a8dc0b1153c611c4cf0dc4a51631f052bb] Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6
git bisect good 3516c6a8dc0b1153c611c4cf0dc4a51631f052bb
# bad: [3989203290fba6fdf6bc4825fbf6526e1bf17977] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
git bisect bad 3989203290fba6fdf6bc4825fbf6526e1bf17977
# bad: [d7ca6f8cdffa5765e486edb3dada9121fba8e6aa] Merge branch 'for-linus' of git://git.o-hand.com/linux-rpurdie-backlight
git bisect bad d7ca6f8cdffa5765e486edb3dada9121fba8e6aa
# good: [3b4dadf05d177289c279c50030c7c75e004952bb] Merge branch 'acpi_enforce_resources' into release
git bisect good 3b4dadf05d177289c279c50030c7c75e004952bb
# bad: [32fb6c17566ec66de87324a834c7776f40e35e78] Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
git bisect bad 32fb6c17566ec66de87324a834c7776f40e35e78
# good: [45e36c1666aa6c8b0c538abcf984b336184d8c3f] Merge git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6
git bisect good 45e36c1666aa6c8b0c538abcf984b336184d8c3f
# good: [33526a53600ac887d100e3c9b4be3637ac8ae3a5] Merge branch 'x2apic' into release
git bisect good 33526a53600ac887d100e3c9b4be3637ac8ae3a5
# good: [c542aadeb4700bc316834d862d52ba3d2664f13a] panasonic-laptop: Fix autoloading
git bisect good c542aadeb4700bc316834d862d52ba3d2664f13a
# bad: [478c6a43fcbc6c11609f8cee7c7b57223907754f] Merge branch 'linus' into release
git bisect bad 478c6a43fcbc6c11609f8cee7c7b57223907754f
# good: [15065531c1c5902775ae3ade24eb37d0e688353b] toshiba-acpi: remove MAINTAINERS entry
git bisect good 15065531c1c5902775ae3ade24eb37d0e688353b
# good: [8a3f257c704e02aee9869decd069a806b45be3f1] Merge branch 'misc' into release
git bisect good 8a3f257c704e02aee9869decd069a806b45be3f1

  reply	other threads:[~2009-04-12 16:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-11 14:56 High latency on /sys/class/thermal Tiago Simões Batista
2009-04-11 19:14 ` Andrew Morton
2009-04-11 22:12   ` Tiago Simões Batista
2009-04-11 22:16   ` Tiago Simões Batista
2009-04-12 16:03     ` Tiago Simões Batista [this message]
2009-04-12 16:03       ` Tiago Simões Batista
2009-04-13  1:43       ` Zhang Rui
2009-04-13  1:43         ` Zhang Rui
2009-04-13  2:28         ` Tiago Simões Batista
2009-04-13  3:02           ` Zhang Rui
2009-04-13  3:02             ` Zhang Rui
2009-04-13  3:28             ` Tiago Simões Batista
2009-04-13  5:44               ` Zhang Rui
2009-04-13 15:05                 ` Tiago Simões Batista
2009-04-14  2:11                   ` Zhang Rui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090412170320.52e374df@gmail.com \
    --to=tiagosbatista@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=rui.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.