On Sun, 31 Dec 2006, Arjan van de Ven wrote:
> On Sun, 2006-12-31 at 14:39 +0100, Folkert van Heusden wrote:
> > > > i don't see how that can be true, given that most of the definitions
> > > > of the clear_page() macro are simply invocations of memset(). see for
> > > > yourself:
> > > *MOST*. Not all.
> > > For example an SSE version will at least assume 16 byte alignment, etc
> > > etc.
> >
> > What about an if (adress & 15) { memset } else { sse stuff }
> > or is that too obvious? :-)
>
> it's only one example. clear_page() working only on a full page is a
> nice restriction that allows the implementation to be optimized
> (again the x86 hardware that had a hardware page zeroer comes to
> mind, the hw is only 4 years old or so... and future hw may have it
> again)
>
> clear_page() is more restricted than memset(). And that's good, it
> allows for a more focused implementation. Otherwise there'd be no
> reason to HAVE a clear_page(), if it just was a memset wrapper
> entirely.
(just one more note about this, then i'll stop dragging it out. i
didn't mean to get this long-winded about it.)
arjan, you and i actually agree on this. i fully accept that the idea
of a "clear_page()" call might or should have extra semantics,
compared to the more simple and direct "memset(...,0,PAGE_SIZE)" call
(such as alignment requirements, for example). my observation is
simply that this is not what is currently happening.
consider, for example, how many calls there are to clear_page() in the
drivers directory:
$ grep -rw clear_page drivers
not that many. now how many calls are there of the memset variety?
$ grep -Er "memset(.*0, ?PAGE_SIZE)" drivers
i can't believe that at least *some* of those memset() calls couldn't
be re-written as clear_page() calls. and that's just for the
drivers/ directory.
sure, clear_page() might have extra semantics. but if that's the
case, and those semantics happen to be in play, i'm suggesting that
not only *can* one use clear_page() at that point, one *should* use
it.
put another way, if a given situation is appropriate for a call to
clear_page(), then that's what should be used. because if one sees
instead a call to an equivalent memset(), that might suggest that
there's something *preventing* the use of clear_page() -- that it's
not appropriate. and, really, there's no need to be unnecessarily
confusing.
this is just another example of the basic kernel infrastructure
defining lots of useful features (ARRAY_SIZE, etc.) and lots of
programmers not using them for one reason or another. in this
situation with clear_page(), the semantics of that call should be
defined clearly and, when the situation arises, i think that call
should be used unless there's a clear reason *not* to. it just makes
the code easier to read.
and on that note, i'll let this one go. others are free to follow
up.
rday
-
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/
