mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: john stultz <johnstul@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Roman Zippel <zippel@linux-m68k.org>,
	Atsushi Nemoto <anemo@mba.ocn.ne.jp>,
	clameter@engr.sgi.com, linux-kernel@vger.kernel.org,
	ralf@linux-mips.org, Andi Kleen <ak@muc.de>
Subject: Re: [PATCH] simplify update_times (avoid jiffies/jiffies_64 aliasing problem)
Date: Fri, 03 Mar 2006 12:17:28 -0800	[thread overview]
Message-ID: <1141417048.9727.60.camel@cog.beaverton.ibm.com> (raw)
In-Reply-To: <20060302190408.1e754f12.akpm@osdl.org>

On Thu, 2006-03-02 at 19:04 -0800, Andrew Morton wrote:
> I'm actually creaking under the load of timer patches over here.  A lot of
> the above code has been heavily redone in John's time patches.  I guess the
> above optimisation is still relevant after John's work (?) but we need to
> decide what to do.   Now is as good a time as any.
> 
> John, that timer stuff is so fundamental and hits on code which has
> historically been so fragile that I'm not sure it's even 2.6.17 material. 
> In which case we should sneak patches like the above underneath it all.
>
> Or we decide to take your work into 2.6.17, in which case the above needs
> to be redone for that context.

I'm not opposed to queuing it up as it seems like a logical cleanup. I'd
be fine with it going in before my patch, however it still needs to
address i386 lost tick compensation.  I worry that addressing that issue
before my patchset (which makes the lost tick compensation unnecessary)
might be a bit more complex. I think it would be easier going in after
my patch. I do think the barrier fix (with a comment) is a good short
term fix.

Atsushi: Your thoughts? 


> I'm not sure how to resolve this, really.  Worried.  Have you socialised
> those changes with architecture maintainers?  If so, what was the feedback?

As to the larger issue of if my patch set is 2.6.17 ready, I'd like to
think it is. There are some optimizations I'm working on that Roman has
suggested that should improve some of the periodic_hook overhead and the
NTP accuracy, but so far I've not noticed the changes helping or hurting
much (also I haven't gotten any feedback on my last attempt). I plan on
continuing that work, but I feel the benefits (as in the number of real
problems that it would resolve) for pushing the patchset that is in -mm
without the finer performance tuning is large enough for it to be
considered.

But again, you're concerns are valid, there appears to be a lack of
enthusiasm in the community both for and against the changes. And I
understand, as I've got lots of other things I need to do as well, and
reviewing a large change like this can take some time that I'm sure
folks are short on.

Maybe I should work on selling it more, I just have been at it for so
long with this patch set that I feel I'm boring folks with the constant
and repetitive "provides robust behavior in the face of lost ticks and
enables other development like high-res timers and realtime" schtick.

But I guess I'll try to ping some folks individually see if I can't stir
up some discussion and get some additional feedback on the issue.

thanks
-john



  parent reply	other threads:[~2006-03-03 20:17 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-02 14:02 Atsushi Nemoto
2006-03-02 15:51 ` Atsushi Nemoto
2006-03-02 19:09 ` Christoph Lameter
2006-03-03  2:44   ` Atsushi Nemoto
2006-03-03  3:04     ` Andrew Morton
2006-03-03  3:20       ` Andi Kleen
2006-03-03  4:31       ` Atsushi Nemoto
2006-03-03  5:45         ` David S. Miller
2006-03-03 16:26           ` Atsushi Nemoto
2006-03-03 16:31         ` Atsushi Nemoto
2006-03-04  8:18           ` Andrew Morton
2006-03-04 11:20             ` Andi Kleen
2006-03-04 11:40               ` Andrew Morton
2006-03-04  5:21                 ` Andi Kleen
2006-03-04 23:13                 ` Paul Mackerras
2006-03-06  2:32                   ` Atsushi Nemoto
2006-03-04 11:42               ` Paul Mackerras
2006-03-04 11:44                 ` Andrew Morton
2006-03-04 12:33                   ` Paul Mackerras
2006-03-04 16:43                     ` Atsushi Nemoto
2006-03-03 20:17       ` john stultz [this message]
2006-03-03 21:15         ` Andrew Morton
2006-03-04 17:15         ` Atsushi Nemoto
2006-07-30 14:54           ` Atsushi Nemoto
2006-07-31 10:36             ` Martin Schwidefsky
2006-08-01 14:44               ` Atsushi Nemoto
2006-08-02 12:50                 ` Martin Schwidefsky
2006-08-03 15:53                   ` Atsushi Nemoto
2006-08-04 14:02                     ` Martin Schwidefsky
2006-08-06 16:13                       ` Atsushi Nemoto
2006-08-07 11:28                         ` Martin Schwidefsky
2006-08-07 19:58                         ` Andrew Morton
2006-08-08  8:11                           ` Martin Schwidefsky
2006-08-09 15:07                           ` Atsushi Nemoto
2006-03-03 18:13     ` john stultz
2006-03-04  2:34       ` Ralf Baechle

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=1141417048.9727.60.camel@cog.beaverton.ibm.com \
    --to=johnstul@us.ibm.com \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=anemo@mba.ocn.ne.jp \
    --cc=clameter@engr.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ralf@linux-mips.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®