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
21 matches
Mail list logo
