Hello everybody
I patched yesterday the 2.5.47 vanilla kernel with Akira
Tsukamoto's Athlon copy_user patch and tried a
hdparm -tT /dev/hda
The results (atached) are impressive compared with both the
vanilla 2.5.47 kernel and the 2.4.19 with ck-rl5 patches (from
colivas)
Bye
Calin
=====
--
A mouse is a device used to point at
the xterm you want to type in.
Kim Alm on a.s.r.
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais !
Yahoo! Mail : http://fr.mail.yahoo.com
Hi Calin,
> 2.5.47 with copy user patch
>
> /dev/hda:
> Timing buffer-cache reads: 128 MB in 0.71 seconds =180.28 MB/sec
> Timing buffered disk reads: 64 MB in 4.06 seconds = 15.78 MB/sec
>
>
> vanila 2.5.47
>
> /dev/hda:
> Timing buffer-cache reads: 128 MB in 1.09 seconds =117.32 MB/sec
> Timing buffered disk reads: 64 MB in 4.05 seconds = 15.78 MB/sec
Thank you for trying,
I also been using for compiling kernel for several days,
but, as Andi mentioned, currently the aki_copy is *dangerous*
when any processes/threads ara using fpu register.
I read the code of laze FPU state saving and confirmed that
if the function does not generate exception than
'kernel_fpu_begin/end()' should assure fpu safe inside kernel.
However, it is not enough where exception could rise, as Takahashi
mentioned.
I also have benchmark for small buffer which is enough to fit in cache
which I would like to show that aki_copy does perform well for this
circumstances.
But I have something urgent todo(homework :)) and I will come back to it
as soon as possible.
Thank you,
Akira Tsukamoto
On Tue, 19 Nov 2002 18:34:16 +0100 (CET)
szonyi calin <[email protected]> mentioned:
> Hello everybody
>
> I patched yesterday the 2.5.47 vanilla kernel with Akira
> Tsukamoto's Athlon copy_user patch and tried a
> hdparm -tT /dev/hda
>
> The results (atached) are impressive compared with both the
> vanilla 2.5.47 kernel and the 2.4.19 with ck-rl5 patches (from
> colivas)
>
> Bye
>
> Calin
>
>
>
> =====
> --
> A mouse is a device used to point at
> the xterm you want to type in.
> Kim Alm on a.s.r.
>
> ___________________________________________________________
> Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran軋is !
> Yahoo! Mail : http://fr.mail.yahoo.com
--
Akira Tsukamoto <[email protected], [email protected]>
Hi Calin,
> 2.5.47 with copy user patch
>
> /dev/hda:
> Timing buffer-cache reads: 128 MB in 0.71 seconds =180.28 MB/sec
> Timing buffered disk reads: 64 MB in 4.06 seconds = 15.78 MB/sec
>
>
> vanila 2.5.47
>
> /dev/hda:
> Timing buffer-cache reads: 128 MB in 1.09 seconds =117.32 MB/sec
> Timing buffered disk reads: 64 MB in 4.05 seconds = 15.78 MB/sec
Thank you for trying,
I also been using for compiling kernel for several days,
but, as Andi mentioned, currently the aki_copy is *dangerous*
when any processes/threads ara using fpu register.
I read the code of laze FPU state saving and confirmed that
if the function does not generate exception than
'kernel_fpu_begin/end()' should assure fpu safe inside kernel.
However, it is not enough where exception could rise, as Takahashi
mentioned.
I also have benchmark for small buffer which is enough to fit in cache
which I would like to show that aki_copy does perform well for this
circumstances.
But I have something urgent todo(homework :)) and I will come back to it
as soon as possible.
Thank you,
Akira Tsukamoto
On Tue, 19 Nov 2002 18:34:16 +0100 (CET)
szonyi calin <[email protected]> mentioned:
> Hello everybody
>
> I patched yesterday the 2.5.47 vanilla kernel with Akira
> Tsukamoto's Athlon copy_user patch and tried a
> hdparm -tT /dev/hda
>
> The results (atached) are impressive compared with both the
> vanilla 2.5.47 kernel and the 2.4.19 with ck-rl5 patches (from
> colivas)
>
> Bye
>
> Calin
>
>
>
> =====
> --
> A mouse is a device used to point at
> the xterm you want to type in.
> Kim Alm on a.s.r.
>
> ___________________________________________________________
> Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran軋is !
> Yahoo! Mail : http://fr.mail.yahoo.com
--
Akira Tsukamoto <[email protected], [email protected]>
>I read the code of laze FPU state saving and confirmed that
>if the function does not generate exception than
>'kernel_fpu_begin/end()' should assure fpu safe inside kernel.
>
>However, it is not enough where exception could rise, as Takahashi
>mentioned.
I had prototyped an exception safe kfpu framework, but then I didn't have the time to submit/cleanup it.
http://www.colorfullife.com/~manfred/linux-2.5/sse/patch-kfpu
Have you tried SSE based copy_to_user? With SSE, you can just save the affected registers, without unexpected sideeffects.
--
Manfred
Not deeply but I looked your exception safe kfpu.
'kernel_fpu_begin/end' was like delayed FPU sate switching,
on the other hand, kfpu is more abstracted FPU semaphore
which works per cpu.
I have not compiled it but it should work fine on 2.4, but
have some questions using kfpu for 2.5.
1)Is 'per CPU' safe for 2.5?
I think the new O(1) scheduler has process migration between cpus
and I am a bit afraid.
If not safe, any good idea for it?
May be per task could be safer even not optimal for smp?
2)Need to add preempt_disable/enable().
3)struct kfpuacquire {} kfpuacquire; is in the kfpu.h header,
might cause compile problem.
> Have you tried SSE based copy_to_user? With SSE, you can just save the affected registers, without unexpected sideeffects.
No, my CPU don't run SSE......:)
By the way,
do you have separeted patch only for kfpu?
Thank you,
Akira Tsukamoto
On Tue, 19 Nov 2002 20:18:25 +0100
Manfred Spraul <[email protected]> mentioned:
> >I read the code of laze FPU state saving and confirmed that
> >if the function does not generate exception than
> >'kernel_fpu_begin/end()' should assure fpu safe inside kernel.
> >
> >However, it is not enough where exception could rise, as Takahashi
> >mentioned.
>
>
> I had prototyped an exception safe kfpu framework, but then I didn't have the time to submit/cleanup it.
>
> http://www.colorfullife.com/~manfred/linux-2.5/sse/patch-kfpu
>
> Have you tried SSE based copy_to_user? With SSE, you can just save the affected registers, without unexpected sideeffects.
>
> --
> Manfred
>
>
> -
> 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/
--
Akira Tsukamoto <[email protected], [email protected]>