Re: [ANNOUNCE] ktimers subsystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Sat, 24 Sep 2005, Ingo Molnar wrote:

> > Anyway, the biggest cost is the conversion from/to the 64bit ns value 
> > [...]
> 
> Where do you get that notion from? Have you personally measured the 
> performance and code size impact of it? If yes, would you mind to share 
> the resulting data with us?
> 
> Our data is that the use of 64-bit nsec_t significantly reduces the size 
> of a representative piece of code (object size in bytes):
> 
>                 AMD64    I386        ARM          PPC32       M68K
>    nsec_t_ops   226      284         252          428         206
>    timespec_ops 412      324         448          640         342
> 
> i.e. a ~40% size reduction when going to nsec_t on m68k, in that 
> particular function. Even larger, ~45% code size reduction on a true 
> 64-bit platform.

Without any source these numbers are not verifiable. You don't even 
mention here what that "representative piece of code" is...

Anyway, Thomas mentioned that this would be from the insert/remove code 
and here you omitted the most important part of my mail:

typedef union {
	u64 tv64;
	struct {
#ifdef __BIG_ENDIAN
		u32 sec, nsec;
#else
		u32 nsec, sec;
#endif
	} tv;
} ktimespec;

IOW this would allow to keep the time value in timespec format and use 
your nsec_t_ops for sorting.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux