[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100122154006.GA4975@sgi.com>
Date: Fri, 22 Jan 2010 09:40:06 -0600
From: Dimitri Sivanich <sivanich@....com>
To: Ingo Molnar <mingo@...e.hu>
Cc: linux-kernel@...r.kernel.org, Jack Steiner <steiner@....com>,
"H. Peter Anvin" <hpa@...or.com>, tglx@...utronix.de
Subject: Re: [PATCH] x86, UV: Fix RTC latency bug by reading replicated
cachelines
On Wed, Jan 20, 2010 at 09:10:20AM +0100, Ingo Molnar wrote:
>
> * Dimitri Sivanich <sivanich@....com> wrote:
>
> > +++ linux/drivers/char/uv_mmtimer.c 2010-01-14 11:56:57.000000000 -0600
> > @@ -89,12 +89,19 @@ static long uv_mmtimer_ioctl(struct file
> > switch (cmd) {
> > case MMTIMER_GETOFFSET: /* offset of the counter */
> > /*
> > - * UV RTC register is on its own page
> > + * Starting with HUB rev 2.0, the UV RTC register is
> > + * replicated across all cachelines of it's own page.
> > + * This allows faster simultaneous reads from a given socket.
> > + *
> > + * The offset returned is in 64 bit units.
> > */
> > - if (PAGE_SIZE <= (1 << 16))
> > - ret = ((UV_LOCAL_MMR_BASE | UVH_RTC) & (PAGE_SIZE-1))
> > - / 8;
> > - else
> > + if (PAGE_SIZE <= (1 << 16)) {
> > + if (uv_get_min_hub_revision_id() == 1)
> > + ret = 0;
> > + else
> > + ret = ((uv_blade_processor_id() *
> > + L1_CACHE_BYTES) % PAGE_SIZE) / 8;
> > + } else
>
> That 64K PAGE_SIZE check in the ioctl looks rather weird. What is the purpose
> of it?
Checking for > 64k pages is really a holdover from similar code on ia64. I've taken it out with a modified version of this patch that I'll send shortly.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists