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
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
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
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
> >
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
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
> 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:
>
>
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
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 as a
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?
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:
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 with an
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 optimalisations should
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
> > 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
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
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
> 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
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*.
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
> > 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) {
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
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
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
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
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 example
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 most of
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 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
> 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
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
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_page()
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)
the majority of
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 are
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
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 calling
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
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/arch/page.h header file, but not entirely
42 matches
Mail list logo
