Messages in this thread | | | Date | Fri, 12 Nov 2004 08:06:12 +0100 | From | Willy Tarreau <> | Subject | Re: CONFIG_X86_PM_TIMER is slow |
| |
On Thu, Nov 11, 2004 at 10:16:27PM -0800, dean gaudet wrote: > On Fri, 12 Nov 2004, Willy Tarreau wrote: > > > On Thu, Nov 11, 2004 at 09:52:27PM -0800, dean gaudet wrote: > > > when using CONFIG_X86_PM_TIMER i'm finding that gettimeofday() calls take > > > 2.8us on a p-m 1.4GHz box... which is an order of magnitude slower than > > > TSC-based solutions. > > > > > > on one workload i'm seeing a 7% perf improvement by booting "acpi=off" to > > > force it to use tsc instead of the PM timer... (the workload calls > > > gettimeofday too frequently, but i can't change that). > > > > I did not test, this might be interesting. > > In fact, what would be very good would be sort of a new select/poll/epoll > > syscalls with an additional argument, which would point to a structure > > that the syscall would fill in return with the time of day. This would > > greatly reduce the number of calls to gettimeofday() in some programs, > > and make use of the time that was used by the syscall itself. > > > > For example, if I could call it like this, it would be really cool : > > > > ret = select_absdate(&in, &out, &excp, &date_timeout, &return_date); > > but the overhead isn't the syscall :) it's the pm timer itself... the > program below reads the pm timer the same way the kernel does and you can > see it takes 2.5us to read it...
Sorry, what I meant is that if the select() did filled the structure itself, it would avoid a supplementary call (syscall+hw access). And I'm certain that select() accesses the same information at some time.
> # cc -O2 -g -Wall readport.c -o readport > # grep PM-Timer /var/log/dmesg > ACPI: PM-Timer IO Port: 0xd808 > # time ./readport 0xd808 1000000 > ./readport 0xd808 1000000 2.54s user 0.00s system 100% cpu 2.526 total > > the gettimeofday overhead is dominated by this i/o...
Indeed, this is much !
> /* It has been reported that because of various broken > * chipsets (ICH4, PIIX4 and PIIX4E) where the ACPI PM time > * source is not latched, so you must read it multiple > * times to insure a safe value is read. > */ > do { > v1 = inl(pmtmr_ioport); > v2 = inl(pmtmr_ioport); > v3 = inl(pmtmr_ioport); > } while ((v1 > v2 && v1 < v3) || (v2 > v3 && v2 < v1) > || (v3 > v1 && v3 < v2));
Just a thought : have you tried to check whether it's the recovery time after a read or read itself which takes time ? I mean, perhaps one read would take, say 50 ns, but two back-to-back reads will take 2 us. If this is the case, having a separate function with only one read for non-broken chipsets will be better because there might be no particular reasons to check the counter that often.
Other thought : is it possible to memory-map this timer to avoid the slow inl() on x86 ?
Regards, Willy
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |