Re: File corruption when using kernels 2.6.18+

2007-10-03 Thread Hiro Yoshioka
Hi, From: Linus Torvalds <[EMAIL PROTECTED]> > On Wed, 3 Oct 2007, Pekka Enberg wrote: > > > > On 10/3/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > I would bet that the reason the intel-optimized memcpy triggers this is > > > that the non-temporal stores just means that you go out directly

Re: How innovative is Linux?

2007-06-25 Thread Hiro Yoshioka
ommunity is very innovative. Linux is the first OS developed by very large community. (Bazaar Model) Regards, Hiro -- Hiro Yoshioka mailto:hyoshiok at miraclelinux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTEC

Re: [RFD] Documentation/HOWTO translated into Japanese

2007-06-11 Thread Hiro Yoshioka
s file with patches that happen to modify the originals. That way they can easily keep up with the minor number of changes that happen over time. I think that some members of YLUG (Yokohama Linux Users Group) may help to review the translations. :-) Regards, Hiro -- Hiro Yoshioka mailto:hyoshio

Re: SMP performance degradation with sysbench

2007-02-27 Thread Hiro Yoshioka
From: Robert Hancock <[EMAIL PROTECTED]> Subject: Re: SMP performance degradation with sysbench Date: Tue, 27 Feb 2007 18:20:25 -0600 Message-ID: <[EMAIL PROTECTED]> > Hiro Yoshioka wrote: > > Howdy, > > > > MySQL 5.0.26 had some scalability issues an

Re: SMP performance degradation with sysbench

2007-02-26 Thread Hiro Yoshioka
Hi, From: Rik van Riel <[EMAIL PROTECTED]> > Hiro Yoshioka wrote: > > Howdy, > > > > MySQL 5.0.26 had some scalability issues and it solved since 5.0.32 > > http://ossipedia.ipa.go.jp/capacity/EV0612260303/ > > (written in Japanese but you may read the

Re: SMP performance degradation with sysbench

2007-02-26 Thread Hiro Yoshioka
ROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Regards, Hiro -- Hiro Yoshioka mailto:hyoshiok at miraclelinux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: x86-cache-pollution-aware-__copy_from_user_ll.patch added to -mm tree

2005-09-04 Thread Hiro Yoshioka
From: Andrew Morton <[EMAIL PROTECTED]> > Dave Jones <[EMAIL PROTECTED]> wrote: > > > > On Sun, Sep 04, 2005 at 01:16:00PM -0700, Andrew Morton wrote: > > > unsigned long __copy_to_user_ll(void __user *to, const void *from, > > unsigned long n) > > > { > > > BUG_ON((long) n < 0);

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-09-03 Thread Hiro Yoshioka
From: Hiro Yoshioka <[EMAIL PROTECTED]> Subject: Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll() Date: Fri, 02 Sep 2005 13:37:16 +0900 (JST) Message-ID: <[EMAIL PROTECTED]> > From: Andrew Morton <[EMAIL PROTECTED]> > > Hiro Yoshioka <[EMAIL PROTECTED]

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-09-01 Thread Hiro Yoshioka
From: Andrew Morton <[EMAIL PROTECTED]> > Hiro Yoshioka <[EMAIL PROTECTED]> wrote: > > > > --- linux-2.6.12.4.orig/arch/i386/lib/usercopy.c2005-08-05 > > 16:04:37.0 +0900 > > +++ linux-2.6.12.4.nt/arch/i386/lib/usercopy.c 2005-09-01 &

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-09-01 Thread Hiro Yoshioka
Andrew, From: Andrew Morton <[EMAIL PROTECTED]> > Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > On Friday 02 September 2005 04:08, Andrew Morton wrote: > > > > > I suppose I'll queue it up in -mm for a while, although I'm a bit dubious > > > about the whole idea... We'll gain some and we'll lose

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-09-01 Thread Hiro Yoshioka
From: Andi Kleen <[EMAIL PROTECTED]> > On Thursday 01 September 2005 11:07, Hiro Yoshioka wrote: > > > The following is the almost final version of the > > cache pollution aware __copy_from_user_ll() patch. > > Looks good to me. > > Once the filemap.c h

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-09-01 Thread Hiro Yoshioka
Hi, > From: Andi Kleen <[EMAIL PROTECTED]> > > > Hi, > > > > > > The following patch does not use MMX regsiters so that we don't have > > > to worry about save/restore the FPU/MMX states. > > > > > > What do you think? > > > > Performance will probably be bad on K7 Athlons - those have a microc

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-24 Thread Hiro Yoshioka
From: Andi Kleen <[EMAIL PROTECTED]> > > Hi, > > > > The following patch does not use MMX regsiters so that we don't have > > to worry about save/restore the FPU/MMX states. > > > > What do you think? > > Performance will probably be bad on K7 Athlons - those have a microcoded > movnti which is

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-24 Thread Hiro Yoshioka
From: Hirokazu Takahashi <[EMAIL PROTECTED]> > > The following patch does not use MMX regsiters so that we don't have > > to worry about save/restore the FPU/MMX states. > > > > What do you think? > > I think __copy_user_zeroing_intel_nocache() should be followed by sfence > or mfence instruction

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-24 Thread Hiro Yoshioka
{ + might_sleep(); + return __copy_from_user_inatomic_nocache(to, from, n); +} + unsigned long __must_check copy_to_user(void __user *to, const void *from, unsigned long n); unsigned long __must_check copy_from_user(void *to, diff -ur linux-2.6.12.4.orig/mm/filemap.c linux

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-22 Thread Hiro Yoshioka
Hi, It seems to me this mail does not go out. So resending it. > On 8/18/05, Hiro Yoshioka <[EMAIL PROTECTED]> wrote: > > 1) using stack to save/restore MMX registers > > It seems to me that it has some regression. > I'd like to rollback it and use kernel_fpu_begin

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-22 Thread Hiro Yoshioka
Hi, It seems to me this mail does not go out. So resending it. > On 8/18/05, Hiro Yoshioka <[EMAIL PROTECTED]> wrote: > > 1) using stack to save/restore MMX registers > > It seems to me that it has some regression. > I'd like to rollback it and use kernel_fpu_begin

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-22 Thread Hiro Yoshioka
> On 8/18/05, Hiro Yoshioka <[EMAIL PROTECTED]> wrote: > > 1) using stack to save/restore MMX registers > > It seems to me that it has some regression. > I'd like to rollback it and use kernel_fpu_begin() and kernel_fpu_end(). The following is a current version of

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-18 Thread Hiro Yoshioka
Hi, On 8/18/05, Hiro Yoshioka <[EMAIL PROTECTED]> wrote: > 1) using stack to save/restore MMX registers It seems to me that it has some regression. I'd like to rollback it and use kernel_fpu_begin() and kernel_fpu_end(). Regards, Hiro -- Hiro Yoshioka mailto:hyoshiok at miracle

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-18 Thread Hiro Yoshioka
rom, 1, ret, 1); + return ret; + case 2: + __get_user_size(*(u16 *)to, from, 2, ret, 2); + return ret; + case 4: + __get_user_size(*(u32 *)to, from, 4, ret, 4); + re

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-18 Thread Hiro Yoshioka
low latency version and the other is a throughput version. What do you think? Regards, Hiro -- Hiro Yoshioka mailto:hyoshiok at miraclelinux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More m

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-18 Thread Hiro Yoshioka
Chuck, On 8/18/05, Chuck Ebbert <[EMAIL PROTECTED]> wrote: > On Wed, 17 Aug 2005 at 13:50:22 +0900 (JST), Hiro Yoshioka wrote: > > > 3) page faults/exceptions/... > > 3-1 TS flag is set by the CPU (Am I right?) > > TS will _not_ be set if a trap/fault or int

Re: math_state_restore() question

2005-08-17 Thread Hiro Yoshioka
> Just take a look at __switch_to(), where __unlazy_fpu() is called. Thanks. Does an exception handler (like page_fault, etc) come from __switch_to()? Regards, Hiro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majo

math_state_restore() question

2005-08-17 Thread Hiro Yoshioka
truct task_struct *tsk = thread->task; clts(); /* Allow maths ops (or we recurse) */ if (!tsk_used_math(tsk)) init_fpu(tsk); restore_fpu(tsk); thread->status |= TS_USEDFPU; /* So we fnsave on switch_to() */ } Thanks in advance, Hi

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-16 Thread Hiro Yoshioka
. Hiro, does it help you? Thanks. I'm reading your patch but could not understand very well. I'll ask you. Regards, Hiro -- Hiro Yoshioka mailto:hyoshiok at miraclelinux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-16 Thread Hiro Yoshioka
From: Hiro Yoshioka <[EMAIL PROTECTED]> Subject: Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll() Date: Wed, 17 Aug 2005 08:21:53 +0900 (JST) Message-ID: <[EMAIL PROTECTED]> > Chuck, > > From: Chuck Ebbert <[EMAIL PROTECTED]> > > On Tue, 16 Aug 2

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-16 Thread Hiro Yoshioka
Chuck, From: Chuck Ebbert <[EMAIL PROTECTED]> > On Tue, 16 Aug 2005 at 19:16:17 +0900 (JST), Hiro Yoshioka wrote: > > oh, really? Does the linux kernel take care of > > SSE save/restore on a task switch? > > Check out XMMS_SAVE and XMMS_RESTORE in include/asm-

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-16 Thread Hiro Yoshioka
From: Arjan van de Ven <[EMAIL PROTECTED]> > > My code does nothing do it. > > > > I need a volunteer to implement it. > > it's actually not too hard; all you need is to use SSE and not MMX; and > then just store sse register you're overwriting on the stack or so... oh, really? Does the linux ke

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-15 Thread Hiro Yoshioka
Takahashi san, I appreciate your comments. > Hi, > > BTW, what are you going to do with the page-faults which may happen > during __copy_user_zeroing_nocache()? The current process may be blocked > in the handler for a while and get FPU registers polluted. > kernel_fpu_begin() won't help the cas

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-15 Thread Hiro Yoshioka
From: Hiro Yoshioka <[EMAIL PROTECTED]> Date: Tue, 16 Aug 2005 08:33:59 +0900 > Thanks. > > filemap_copy_from_user() calls __copy_from_user_inatomic() calls > __copy_from_user_ll(). > > I'll look at the code. The following is a quick hack of cache aware implemen

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-15 Thread Hiro Yoshioka
e the most difference will be > in the VFS for the write() system call, and the AIO variants thereof. > > generic_file_buffered_write() will be a good candidate to try first... Thanks. filemap_copy_from_user() calls __copy_from_user_inatomic() calls __copy_from_user_ll(). I'll

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-15 Thread Hiro Yoshioka
Hi, I appreciate your suggestion. On 8/15/05, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > > > Anyway we could not find the cache aware version of __copy_from_user_ll > > has a big regression yet. > > > that is because you spread the cache misses out from one place to all > over the place, so

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-14 Thread Hiro Yoshioka
Hi, From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll() Date: Sun, 14 Aug 2005 12:35:43 +0200 Message-ID: <[EMAIL PROTECTED]> > On Sun, 2005-08-14 at 19:22 +0900, Hiro Yoshioka wrote: > > Thanks for your comments

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-14 Thread Hiro Yoshioka
Thanks for your comments. On 8/14/05, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > On Sun, 2005-08-14 at 18:16 +0900, Hiro Yoshioka wrote: > > Hi, > > > > The following is a patch to reduce a cache pollution > > of __copy_from_user_ll(). > > > >

[RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-14 Thread Hiro Yoshioka
Hi, The following is a patch to reduce a cache pollution of __copy_from_user_ll(). When I run simple iozone benchmark to find a performance bottleneck of the linux kernel, I found that __copy_from_user_ll() spent CPU cycle most and it did many cache misses. The following is profiled by oprofile.