All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Daniel Walker <dwalker@mvista.com>
Cc: akpm@osdl.org, johnstul@us.ibm.com, mingo@elte.hu,
	zippel@linux-m68k.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: + clocksource-add-generic-sched_clock.patch added to -mm tree
Date: Mon, 09 Oct 2006 10:09:37 +0200	[thread overview]
Message-ID: <1160381377.5686.192.camel@localhost.localdomain> (raw)
In-Reply-To: <1160348466.3693.203.camel@c-67-180-230-165.hsd1.ca.comcast.net>

On Sun, 2006-10-08 at 16:01 -0700, Daniel Walker wrote:
> > You move tons of code into timer.c, which does not belong there.
> > clocksource is a different thing than timekeeping. timekeeping makes use
> > of clocksources, and your extra layer of timekeeping_clocksource API
> > does not change that at all. What you call abstraction is just an
> > artificial extra layer, as it is intrinsically tied to the clocksource
> > core.
> 
> I think that code does belong there. Yes clocksources and timekeeping
> are different. Which is the point of the patch set.

And I have to accept that you think, that the code belongs there ?

> It's not less maintainable now, or if it is your going to have to be a
> lot more specific.

In order to satisfy your idea of abstraction, you add glue code to make
it work:

clocksource.c:
> +int clocksource_sysfs_register(struct sysdev_attribute * attr)
> +{
> +       return sysdev_create_file(&device_clocksource, attr);
> +}
> +

timer.c:
> +
> +#ifdef CONFIG_GENERIC_TIME
> +       clocksource_sysfs_register(&attr_timeofday_clocksource);

Abstractions are good in general, but this is artificial for no benefit.


You claim, that you optmize update_wll_time()

>         /* check to see if there is a new clocksource to use */
> -       if (change_clocksource()) {
> +       if (unlikely(atomic_read(&clock_check))) {
> +
> +               /*
> +                * Switch to the new override clock, or the highest
> +                * rated clock.
> +                */
> +               if (*clock_override_name)
> +                       change_clocksource(clock_override_name);
> +               else
> +                       change_clocksource(NULL);
> +
>                 clock->error = 0;
>                 clock->xtime_nsec = 0;
>                 hrtimer_clock_notify();
>                 clocksource_calculate_interval(clock, tick_nsec);
> +
> +               /*
> +                * Remove the change signal
> +                */
> +               atomic_dec(&clock_check);
> +
>         }

Well, I guess I have some perceptional disturbance. What exactly is the
optimization ? Pushing clock_override_name into that code path ? As I
said before, the performance difference of change_clocksource() and
atomic_read() is not big enough to justify the mess you create all over
the place.

The whole notifier business is not necessary, if you keep the
clocksource related code in one place. 

You break sched_clock on x86 for no good reason.

	tglx



  reply	other threads:[~2006-10-09  8:09 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200610070153.k971ruEZ020872@shell0.pdx.osdl.net>
2006-10-08  9:55 ` + clocksource-add-generic-sched_clock.patch added to -mm tree Thomas Gleixner
2006-10-08 14:45   ` Daniel Walker
2006-10-08 14:51     ` Thomas Gleixner
2006-10-08 15:32       ` Daniel Walker
2006-10-08 15:46         ` Thomas Gleixner
2006-10-08 16:06           ` Daniel Walker
2006-10-08 16:19             ` Thomas Gleixner
2006-10-08 16:27               ` Daniel Walker
2006-10-08 16:54                 ` Thomas Gleixner
2006-10-08 17:26                   ` Daniel Walker
2006-10-08 18:45                     ` Thomas Gleixner
2006-10-08 21:15                       ` Daniel Walker
2006-10-08 21:21                         ` Thomas Gleixner
2006-10-08 21:33                           ` Daniel Walker
2006-10-08 21:41                             ` Thomas Gleixner
2006-10-08 22:08                               ` Daniel Walker
2006-10-08 22:35                                 ` Thomas Gleixner
2006-10-08 23:01                                   ` Daniel Walker
2006-10-09  8:09                                     ` Thomas Gleixner [this message]
2006-10-08 18:40   ` Ingo Molnar

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=1160381377.5686.192.camel@localhost.localdomain \
    --to=tglx@linutronix.de \
    --cc=akpm@osdl.org \
    --cc=dwalker@mvista.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=zippel@linux-m68k.org \
    /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.