public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Akira Tsukamoto <at541@columbia.edu>
Cc: linux-kernel@vger.kernel.org, Hirokazu Takahashi <taka@valinux.co.jp>
Subject: Re: [PATCH] 2/2 2.5.45 cleanup & add original copy_ro/from_user
Date: Sat, 02 Nov 2002 20:04:32 -0800	[thread overview]
Message-ID: <3DC4A050.EF65975@digeo.com> (raw)
In-Reply-To: 20021102210737.3794.AT541@columbia.edu

Akira Tsukamoto wrote:
> 
> > - smaller is faster
> 
> It could be said more efficient but faster?

Yes, faster.  From a whole-system point of view, which is after
all what we care about.

Cache misses are terribly expensive.

> The code or binary size directly connected to this issue?
> 

Sure.  Large cache footprints in the kernel require more cache
reloads by the kernel and cause more cache reloads on return
to userspace.  Thrashing.

> From my patch, about the speed:
> for PIII/4 CPU -> no change. using the same 2.5.45 copy.
> for old i386 -> more optimal.
> for Athlon -> 2.5.45 does not use unrolled copy for it either.

OK.  Please integrate you patch into the current kernel's usercopy.c.

> I am away for a while but I grew up in Japan and just wanted to save
> some rooms for a embedded system like below.
> http://linux.ascii24.com/linux/news/today/2000/05/22/imageview/images461056.jpg.html
> The phisical size(not kernel) is about 5cm*5cm.
> Is your copy function suitable in this case?

Well it won't hurt, but it looks like yours improves on it.

The thing which requires some thought is "should the decision
be made at compile time or runtime".  For Athlon vs Intel
and i386 vs others, it should be performed at compile time.

  reply	other threads:[~2002-11-03  3:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-02  8:06 [PATCH] 2/2 2.5.45 cleanup & add original copy_ro/from_user Akira Tsukamoto
2002-11-02 10:32 ` Andrew Morton
2002-11-02 11:07   ` Akira Tsukamoto
2002-11-02 18:13     ` Andrew Morton
2002-11-03  2:43       ` Akira Tsukamoto
2002-11-03  4:04         ` Andrew Morton [this message]
2002-11-03  2:43       ` Akira Tsukamoto
2002-11-03  2:57   ` Akira Tsukamoto
2002-11-03 21:24     ` Dave Jones
2002-11-03 22:22       ` Andries Brouwer
     [not found] <20021102025838.220E.AT541@columbia.edu.suse.lists.linux.kernel>
     [not found] ` <3DC3A9C0.7979C276@digeo.com.suse.lists.linux.kernel>
2002-11-02 10:58   ` Andi Kleen
2002-11-02 11:03     ` Andrew Morton
2002-11-02 16:55     ` Denis Vlasenko
2002-11-02 12:09       ` Andi Kleen
2002-11-02 17:08         ` Denis Vlasenko
2002-11-02 12:23           ` Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2002-11-04  3:36 Akira Tsukamoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3DC4A050.EF65975@digeo.com \
    --to=akpm@digeo.com \
    --cc=at541@columbia.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=taka@valinux.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox