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 thos
> 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 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 ch
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:
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
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 ther
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 allo
> 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 consisten
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 network
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 ther
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 linux-ke
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 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 pagefram
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.
>
> T
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 gre
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 kfr
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 p
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 sc
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
22 matches
Mail list logo
