public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/slab.c : prefetchw the start of new allocated objects
Date: Fri, 29 Jul 2005 02:17:22 -0700	[thread overview]
Message-ID: <20050729021722.2e6903e2.akpm@osdl.org> (raw)
In-Reply-To: <42E9F145.7040302@cosmosbay.com>

Eric Dumazet <dada1@cosmosbay.com> wrote:
>
> Most of objects returned by __cache_alloc() will be written by the caller,
>  (but not all callers want to write all the object, but just at the begining)
>  prefetchw() tells the modern CPU to think about the future writes, ie start
>  some memory transactions in advance.

Sounds sensible enough..  slab does try to make sure it returns the
most-recently-freed object, so it's probably in cache already.  But in the
situation where we're allocating and using a lot of objects in succession
it might help.


>  Some CPU lacks a prefetchw() and currently do nothing, so I ask this question :
>  Should'nt make prefetchw() do at least a prefetch() ? A read hint is better than nothing.

Don't think so.  I was once told that if the cacheline is in local cache
for reading and the CPU decides to write to it, additional work is needed
for the write so the prefetch-for-read didn't buy you anything.

  reply	other threads:[~2005-07-29  9:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-26 23:35 2.6.12 sound problem Stephen Clark
2005-07-27  4:23 ` Lee Revell
2005-07-27 15:31   ` Stephen Clark
2005-07-27  8:26 ` Takashi Iwai
2005-07-27 15:31   ` Stephen Clark
2005-07-29  8:41     ` Andrew Morton
2005-07-29  9:05       ` [PATCH] mm/slab.c : prefetchw the start of new allocated objects Eric Dumazet
2005-07-29  9:17         ` Andrew Morton [this message]
2005-07-29 10:08         ` Ingo Molnar
2005-07-30 19:31         ` David S. Miller
2005-07-30  3:13       ` 2.6.12 sound problem Stephen Clark
2005-07-30 15:56         ` Stephen Clark
2005-07-31 19:25           ` 2.6.13rc4 hang Stephen Clark
2005-08-01 13:11           ` Stephen Clark

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=20050729021722.2e6903e2.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=dada1@cosmosbay.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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