On Sun, 31 Dec 2006, Arjan van de Ven wrote:
> So... yes I fully agree with you that it's worth looking at the
> memset( , PAGE_SIZE) users. If they are page aligned, yes absolutely
> make it a clear_page(), I think that's a very good idea. However
> also please check if they've been very recently
On Sat, 30 Dec 2006, Denis Vlasenko wrote:
> I was experimenting with SSE[2] clear_page() which uses
> non-temporal stores. That one requires 16 byte alignment.
>
> BTW, it worked ~300% faster than memset. But Andi Kleen
> insists that cache eviction caused by NT stores will make it
> slower in m
On Mon, Jan 01, 2007 at 05:27:10AM -0500, Robert P. J. Day wrote:
> > both look good... I'd be in favor of this. Maybe also add a part
> > about using GFP_KERNEL whenever possible, GFP_NOFS from filesystem
> > writeout code and GFP_NOIO from block writeout code (and never doing
> > in_interrup
On Mon, 1 Jan 2007 17:42:31 +0900 Paul Mundt wrote:
> On Mon, Jan 01, 2007 at 02:59:32AM +0100, Folkert van Heusden wrote:
> > > > regarding alignment that don't allow clear_page() to be used
> > > > copy_page() in the memcpy() case), but it's going to need a lot of
> >
> > Maybe these optimalisa
On Mon, 1 Jan 2007, Arjan van de Ven wrote:
> > Given the above, some basic suggestions for page-based memory management:
> >
> > (a) If you need to allocate or free a single page, use the single page
> > version of the routine/macro, rather than calling the multi-page
> > version wit
> Given the above, some basic suggestions for page-based memory management:
>
> (a) If you need to allocate or free a single page, use the single page
> version of the routine/macro, rather than calling the multi-page
> version with an order value of zero, such as:
>
> alloc_p
On Mon, Jan 01, 2007 at 02:59:32AM +0100, Folkert van Heusden wrote:
> > > regarding alignment that don't allow clear_page() to be used
> > > copy_page() in the memcpy() case), but it's going to need a lot of
>
> Maybe these optimalisations should be in the coding style docs?
>
For what purpose?
On Mon, 1 Jan 2007, Folkert van Heusden wrote:
> > > regarding alignment that don't allow clear_page() to be used
> > > copy_page() in the memcpy() case), but it's going to need a lot of
>
> Maybe these optimalisations should be in the coding style docs?
i was thinking of submitting the following
> > regarding alignment that don't allow clear_page() to be used
> > copy_page() in the memcpy() case), but it's going to need a lot of
Maybe these optimalisations should be in the coding style docs?
Folkert van Heusden
--
Ever wonder what is out there? Any alien races? Then please support
the
On Mon, 1 Jan 2007, Paul Mundt wrote:
> On Sat, Dec 30, 2006 at 06:04:14PM -0500, Robert P. J. Day wrote:
> > fair enough. *technically*, not every call of the form
> > "memset(ptr,0,PAGE_SIZE)" necessarily represents an address that's on
> > a page boundary. but, *realistically*, i'm guessing m
On Sat, Dec 30, 2006 at 06:04:14PM -0500, Robert P. J. Day wrote:
> fair enough. *technically*, not every call of the form
> "memset(ptr,0,PAGE_SIZE)" necessarily represents an address that's on
> a page boundary. but, *realistically*, i'm guessing most of them do.
> just grabbing a random exampl
> 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
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*. N
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 ass
> > 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) { mems
On Sat, 30 Dec 2006, Arjan van de Ven wrote:
> rday wrote:
> > ... most of the definitions of the clear_page() macro are simply
> > invocations of memset(). see for yourself:
> *MOST*. Not all.
i did notice that. while the majority of the architectures simply
define clear_page() as a macro ca
> 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.
clear_page() is supposed to be for full real pa
On Saturday 30 December 2006 23:08, Robert P. J. Day wrote:
> >
> > clear_page assumes that given address is page aligned, I think. It
> > may fail if you feed it with misaligned region's address.
>
> i don't see how that can be true, given that most of the definitions
> of the clear_page() macro
On Sat, 30 Dec 2006, Denis Vlasenko wrote:
> On Friday 29 December 2006 07:16, Robert P. J. Day wrote:
> >
> > is there some reason there are so many calls of the form
> >
> > memset(addr, 0, PAGE_SIZE)
> >
> > rather than the apparently equivalent invocation of
> >
> > clear_page(addr)
> >
On Friday 29 December 2006 07:16, Robert P. J. Day wrote:
>
> is there some reason there are so many calls of the form
>
> memset(addr, 0, PAGE_SIZE)
>
> rather than the apparently equivalent invocation of
>
> clear_page(addr)
>
> the majority of architectures appear to define the clear_
is there some reason there are so many calls of the form
memset(addr, 0, PAGE_SIZE)
rather than the apparently equivalent invocation of
clear_page(addr)
the majority of architectures appear to define the clear_page() macro
in their include//page.h header file, but not entirely
identicall
21 matches
Mail list logo
