public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: john stultz <johnstul@us.ibm.com>
To: Andy Lutomirski <luto@mit.edu>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@elte.hu>, Clemens Ladisch <clemens@ladisch.de>,
	linux-ia64@vger.kernel.org, Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 4/5] clocksource: Replace vread and fsys_mmio with generic arch data
Date: Tue, 07 Jun 2011 13:28:34 -0700	[thread overview]
Message-ID: <1307478514.3163.49.camel@work-vm> (raw)
In-Reply-To: <4a233d5b7421ef8f7805139e3eba68c52c2d0d57.1307474707.git.luto@mit.edu>

On Tue, 2011-06-07 at 15:32 -0400, Andy Lutomirski wrote:
> The vread field was bloating struct clocksource everywhere except
> x86_64, and I want to change the way this works on x86_64, so let's
> split it out into per-arch data.
[snip]
> diff --git a/arch/ia64/include/asm/clocksource.h b/arch/ia64/include/asm/clocksource.h
> new file mode 100644
> index 0000000..453f363
> --- /dev/null
> +++ b/arch/ia64/include/asm/clocksource.h
> @@ -0,0 +1,16 @@
> +/* x86-specific clocksource additions */
> +
> +#ifndef _ASM_X86_CLOCKSOURCE_H
> +#define _ASM_X86_CLOCKSOURCE_H
> +
> +#ifdef CONFIG_X86_64

Why do we want X86_64 ifdefs in the ia64 clocksource.h?


> +#define __ARCH_HAS_CLOCKSOURCE_DATA
> +
> +struct arch_clocksource_data {
> +	void *fsys_mmio;        /* used by fsyscall asm code */
> +};
> +
> +#endif /* CONFIG_X86_64 */
> +
> +#endif /* _ASM_X86_CLOCKSOURCE_H */
> diff --git a/arch/ia64/kernel/cyclone.c b/arch/ia64/kernel/cyclone.c
> index f64097b..4826ff9 100644
> --- a/arch/ia64/kernel/cyclone.c
> +++ b/arch/ia64/kernel/cyclone.c
> @@ -115,7 +115,7 @@ int __init init_cyclone_clock(void)
>  	}
>  	/* initialize last tick */
>  	cyclone_mc = cyclone_timer;
> -	clocksource_cyclone.fsys_mmio = cyclone_timer;
> +	clocksource_cyclone.archdata.fsys_mmio = cyclone_timer;
>  	clocksource_register_hz(&clocksource_cyclone, CYCLONE_TIMER_FREQ);
> 
>  	return 0;
> diff --git a/arch/ia64/kernel/time.c b/arch/ia64/kernel/time.c
> index 85118df..43920de 100644
> --- a/arch/ia64/kernel/time.c
> +++ b/arch/ia64/kernel/time.c
> @@ -468,7 +468,7 @@ void update_vsyscall(struct timespec *wall, struct timespec *wtm,
>          fsyscall_gtod_data.clk_mask = c->mask;
>          fsyscall_gtod_data.clk_mult = mult;
>          fsyscall_gtod_data.clk_shift = c->shift;
> -        fsyscall_gtod_data.clk_fsys_mmio = c->fsys_mmio;
> +        fsyscall_gtod_data.clk_fsys_mmio = c->archdata.fsys_mmio;
>          fsyscall_gtod_data.clk_cycle_last = c->cycle_last;
> 
>  	/* copy kernel time structures */

Overall this sort of feels a little messy to me. 

While having the ifdefs in the clocksource structure wasn't great, I'm
not super excited about pushing all of this back into arch-specific
code. The hope was that folks like ppc and ia64 would convert over from
their own implementations to using more generic vread() implementations,
or atleast new arches with vdso implementations would make use of it
(possibly even allowing for a generic vdso gettime implementation).

Are there at least some hard numbers that help justify this? Or maybe
could you provide some thoughts on your future plans?

thanks
-john



  reply	other threads:[~2011-06-07 20:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-07 19:32 [PATCH 0/5] Remove remaining executable code from x86-64 vsyscall page Andy Lutomirski
2011-06-07 19:32 ` [PATCH 1/5] x86: Make alternative instruction pointers relative Andy Lutomirski
2011-06-07 19:32 ` [PATCH 2/5] x86-64: Allow alternative patching in the vDSO Andy Lutomirski
2011-06-08 12:33   ` Borislav Petkov
2011-06-07 19:32 ` [PATCH 3/5] x86-64: Add --no-undefined to vDSO build Andy Lutomirski
2011-06-07 19:32 ` [PATCH 4/5] clocksource: Replace vread and fsys_mmio with generic arch data Andy Lutomirski
2011-06-07 20:28   ` john stultz [this message]
2011-06-07 20:35     ` Andrew Lutomirski
2011-06-07 21:06       ` john stultz
2011-06-07 21:18         ` Andrew Lutomirski
2011-06-07 19:32 ` [PATCH 5/5] x86-64: Move vread_tsc and vread_hpet into the vDSO Andy Lutomirski

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=1307478514.3163.49.camel@work-vm \
    --to=johnstul@us.ibm.com \
    --cc=clemens@ladisch.de \
    --cc=fenghua.yu@intel.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@mit.edu \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.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