On Thu, Jun 28, 2007 at 10:24:24PM -0700, Andrew Morton wrote:
> > Really, it would be great if we could treat kmalloc() objects
> > just like real pages.
>
> >From a high level, that seems like a bad idea. kmalloc() gives you a
> virtual address and you really shouldn't be poking around at that
On Sat, Jun 30, 2007 at 12:11:38AM +0100, Alan Cox wrote:
> > DMA to or from memory should be done via the DMA mapping API. If we're
> > DMAing to/from a limited range within a page, either we should be using
> > dma_map_single(), or dma_map_page() with an appropriate offset and size.
>
> If
On Sat, Jun 30, 2007 at 12:11:38AM +0100, Alan Cox wrote:
DMA to or from memory should be done via the DMA mapping API. If we're
DMAing to/from a limited range within a page, either we should be using
dma_map_single(), or dma_map_page() with an appropriate offset and size.
If those
On Thu, Jun 28, 2007 at 10:24:24PM -0700, Andrew Morton wrote:
Really, it would be great if we could treat kmalloc() objects
just like real pages.
From a high level, that seems like a bad idea. kmalloc() gives you a
virtual address and you really shouldn't be poking around at that
> DMA to or from memory should be done via the DMA mapping API. If we're
> DMAing to/from a limited range within a page, either we should be using
> dma_map_single(), or dma_map_page() with an appropriate offset and size.
If those ranges overlap a cache line then the dma mapping API will not
On Fri, 29 Jun 2007 13:45:29 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 29 Jun 2007 13:16:57 +0100
> Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > > If those operations involve modifying that slab page's pageframe then what
> > > stops concurrent dma'ers from stomping on each other's
On Fri, Jun 29, 2007 at 01:45:29PM -0700, Andrew Morton wrote:
> On Fri, 29 Jun 2007 13:16:57 +0100
> Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > > If those operations involve modifying that slab page's pageframe then what
> > > stops concurrent dma'ers from stomping on each other's changes? As
On Fri, 29 Jun 2007 13:16:57 +0100
Alan Cox <[EMAIL PROTECTED]> wrote:
> > If those operations involve modifying that slab page's pageframe then what
> > stops concurrent dma'ers from stomping on each other's changes? As in:
> > why aren't we already buggy?
>
> Or DMA operations falling out
On Fri, 29 Jun 2007, Hugh Dickins wrote:
> I stand by my page_mapping patch, and the remark I made before,
> that page_mapping(page) is the correct place to check this. What is
> page_mapping(page) for? Precisely to return the struct address_space*
> from page->mapping when that's what's in
On Thu, 28 Jun 2007, Christoph Lameter wrote:
> I had a talk with James Bottomley last night and it seems that there is an
> established way of using the page structs of slab objects in the block
> layer. Drivers may use the DMA interfaces to issue control commands. In
> that case they may
> If those operations involve modifying that slab page's pageframe then what
> stops concurrent dma'ers from stomping on each other's changes? As in:
> why aren't we already buggy?
Or DMA operations falling out with CPU operations in the same memory
area. Not all platforms have hardware
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Fri, 29 Jun 2007 00:00:39 -0700 (PDT)
> On Thu, 28 Jun 2007, David Miller wrote:
>
> > Really, it would be great if we could treat kmalloc() objects
> > just like real pages. Everything wants to do I/O on pages
> > but sometimes (like the
On Thu, 28 Jun 2007, David Miller wrote:
> Really, it would be great if we could treat kmalloc() objects
> just like real pages. Everything wants to do I/O on pages
> but sometimes (like the networking) you have a kmalloc
> chunk which is technically just a part of a page.
>
> The fact that
On Thu, 28 Jun 2007, Andrew Morton wrote:
> If those operations _don't_ involve modifying the pageframe (hopes this is
> true) then we're read-only and things become much easier?
This is true right now. We are way off topic ...
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, 28 Jun 2007, David Miller wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Thu, 28 Jun 2007 22:24:24 -0700
>
> > So what happens when two quite different threads of control are doing
> > IO against two hunks of kmalloced memory which happen to come from the same
> > page? Either
On Thu, 28 Jun 2007, David Miller wrote:
From: Andrew Morton [EMAIL PROTECTED]
Date: Thu, 28 Jun 2007 22:24:24 -0700
So what happens when two quite different threads of control are doing
IO against two hunks of kmalloced memory which happen to come from the same
page? Either some
On Thu, 28 Jun 2007, Andrew Morton wrote:
If those operations _don't_ involve modifying the pageframe (hopes this is
true) then we're read-only and things become much easier?
This is true right now. We are way off topic ...
-
To unsubscribe from this list: send the line unsubscribe
On Thu, 28 Jun 2007, David Miller wrote:
Really, it would be great if we could treat kmalloc() objects
just like real pages. Everything wants to do I/O on pages
but sometimes (like the networking) you have a kmalloc
chunk which is technically just a part of a page.
The fact that there is
From: Christoph Lameter [EMAIL PROTECTED]
Date: Fri, 29 Jun 2007 00:00:39 -0700 (PDT)
On Thu, 28 Jun 2007, David Miller wrote:
Really, it would be great if we could treat kmalloc() objects
just like real pages. Everything wants to do I/O on pages
but sometimes (like the networking) you
If those operations involve modifying that slab page's pageframe then what
stops concurrent dma'ers from stomping on each other's changes? As in:
why aren't we already buggy?
Or DMA operations falling out with CPU operations in the same memory
area. Not all platforms have hardware consistency
On Thu, 28 Jun 2007, Christoph Lameter wrote:
I had a talk with James Bottomley last night and it seems that there is an
established way of using the page structs of slab objects in the block
layer. Drivers may use the DMA interfaces to issue control commands. In
that case they may
On Fri, 29 Jun 2007, Hugh Dickins wrote:
I stand by my page_mapping patch, and the remark I made before,
that page_mapping(page) is the correct place to check this. What is
page_mapping(page) for? Precisely to return the struct address_space*
from page-mapping when that's what's in there,
On Fri, 29 Jun 2007 13:16:57 +0100
Alan Cox [EMAIL PROTECTED] wrote:
If those operations involve modifying that slab page's pageframe then what
stops concurrent dma'ers from stomping on each other's changes? As in:
why aren't we already buggy?
Or DMA operations falling out with CPU
On Fri, Jun 29, 2007 at 01:45:29PM -0700, Andrew Morton wrote:
On Fri, 29 Jun 2007 13:16:57 +0100
Alan Cox [EMAIL PROTECTED] wrote:
If those operations involve modifying that slab page's pageframe then what
stops concurrent dma'ers from stomping on each other's changes? As in:
why
On Fri, 29 Jun 2007 13:45:29 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 29 Jun 2007 13:16:57 +0100
Alan Cox [EMAIL PROTECTED] wrote:
If those operations involve modifying that slab page's pageframe then what
stops concurrent dma'ers from stomping on each other's changes? As
DMA to or from memory should be done via the DMA mapping API. If we're
DMAing to/from a limited range within a page, either we should be using
dma_map_single(), or dma_map_page() with an appropriate offset and size.
If those ranges overlap a cache line then the dma mapping API will not
save
On Thu, 28 Jun 2007 22:37:34 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Thu, 28 Jun 2007 22:24:24 -0700
>
> > So what happens when two quite different threads of control are doing
> > IO against two hunks of kmalloced memory which happen
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Thu, 28 Jun 2007 22:24:24 -0700
> So what happens when two quite different threads of control are doing
> IO against two hunks of kmalloced memory which happen to come from the same
> page? Either some (kernel-wide) locking is needed, or that
On Thu, 28 Jun 2007 22:06:06 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote:
> From: Christoph Lameter <[EMAIL PROTECTED]>
> Date: Thu, 28 Jun 2007 21:39:01 -0700 (PDT)
>
> > H... Maybe we are creating more of a mess with this. Isnt there some
> > other way to handle these object.
>
>
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Thu, 28 Jun 2007 21:39:01 -0700 (PDT)
> H... Maybe we are creating more of a mess with this. Isnt there some
> other way to handle these object.
That's where I was going with the silly idea to use another
allocator :)
Really, it would be
On Thu, 28 Jun 2007, David Miller wrote:
> > You can get such a reference and then the slab page will be in limbo if
> > all objects are freed until that reference is given up. The reference
> > method is also use by kmem_cache_vacate() (but that is slab internal).
>
> What about if someone
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Thu, 28 Jun 2007 21:22:22 -0700 (PDT)
> On Thu, 28 Jun 2007, David Miller wrote:
>
> > > Still a better solution would be to not use the slab allocator at all for
> > > the objects that are used to send commands to the devices. These are not
>
On Thu, 28 Jun 2007, David Miller wrote:
> > Still a better solution would be to not use the slab allocator at all for
> > the objects that are used to send commands to the devices. These are not
> > permanent and grabbing a page from the pcp lists and putting it back is
> > likely as fast as
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Thu, 28 Jun 2007 21:01:36 -0700 (PDT)
> Modify the functions in the affected arches to check for PageSlab() and
> use a NULL mapping if such a page is encountered. This may only be
> necessary for parisc and arm since sparc64 and xtensa do not
I had a talk with James Bottomley last night and it seems that there is an
established way of using the page structs of slab objects in the block
layer. Drivers may use the DMA interfaces to issue control commands. In
that case they may allocate a short structure via the slab allocator and
put
I had a talk with James Bottomley last night and it seems that there is an
established way of using the page structs of slab objects in the block
layer. Drivers may use the DMA interfaces to issue control commands. In
that case they may allocate a short structure via the slab allocator and
put
From: Christoph Lameter [EMAIL PROTECTED]
Date: Thu, 28 Jun 2007 21:01:36 -0700 (PDT)
Modify the functions in the affected arches to check for PageSlab() and
use a NULL mapping if such a page is encountered. This may only be
necessary for parisc and arm since sparc64 and xtensa do not scan
On Thu, 28 Jun 2007, David Miller wrote:
Still a better solution would be to not use the slab allocator at all for
the objects that are used to send commands to the devices. These are not
permanent and grabbing a page from the pcp lists and putting it back is
likely as fast as
From: Christoph Lameter [EMAIL PROTECTED]
Date: Thu, 28 Jun 2007 21:22:22 -0700 (PDT)
On Thu, 28 Jun 2007, David Miller wrote:
Still a better solution would be to not use the slab allocator at all for
the objects that are used to send commands to the devices. These are not
permanent
On Thu, 28 Jun 2007, David Miller wrote:
You can get such a reference and then the slab page will be in limbo if
all objects are freed until that reference is given up. The reference
method is also use by kmem_cache_vacate() (but that is slab internal).
What about if someone kfree()'s
From: Christoph Lameter [EMAIL PROTECTED]
Date: Thu, 28 Jun 2007 21:39:01 -0700 (PDT)
H... Maybe we are creating more of a mess with this. Isnt there some
other way to handle these object.
That's where I was going with the silly idea to use another
allocator :)
Really, it would be great
On Thu, 28 Jun 2007 22:06:06 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote:
From: Christoph Lameter [EMAIL PROTECTED]
Date: Thu, 28 Jun 2007 21:39:01 -0700 (PDT)
H... Maybe we are creating more of a mess with this. Isnt there some
other way to handle these object.
That's where
From: Andrew Morton [EMAIL PROTECTED]
Date: Thu, 28 Jun 2007 22:24:24 -0700
So what happens when two quite different threads of control are doing
IO against two hunks of kmalloced memory which happen to come from the same
page? Either some (kernel-wide) locking is needed, or that pageframe
On Thu, 28 Jun 2007 22:37:34 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote:
From: Andrew Morton [EMAIL PROTECTED]
Date: Thu, 28 Jun 2007 22:24:24 -0700
So what happens when two quite different threads of control are doing
IO against two hunks of kmalloced memory which happen to come
44 matches
Mail list logo
