On Wed, 20 Jun 2007 10:06:39 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-06-19 at 14:37 -0700, Keshavamurthy, Anil S wrote:
> > plain text document attachment (intel_iommu_pf_memalloc.patch)
> > Intel IOMMU driver needs memory during DMA map calls to setup its internal
> > page
On Wed, 20 Jun 2007 10:06:39 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
On Tue, 2007-06-19 at 14:37 -0700, Keshavamurthy, Anil S wrote:
plain text document attachment (intel_iommu_pf_memalloc.patch)
Intel IOMMU driver needs memory during DMA map calls to setup its internal
page tables
On Thu, Jun 21, 2007 at 09:13:11AM +0200, Peter Zijlstra wrote:
> On Wed, 2007-06-20 at 23:37 -0700, Keshavamurthy, Anil S wrote:
> > On Thu, Jun 21, 2007 at 08:29:34AM +0200, Peter Zijlstra wrote:
> > > On Wed, 2007-06-20 at 23:11 -0700, Arjan van de Ven wrote:
> > > > Peter Zijlstra wrote:
> > >
On Wed, 2007-06-20 at 23:37 -0700, Keshavamurthy, Anil S wrote:
> On Thu, Jun 21, 2007 at 08:29:34AM +0200, Peter Zijlstra wrote:
> > On Wed, 2007-06-20 at 23:11 -0700, Arjan van de Ven wrote:
> > > Peter Zijlstra wrote:
> > Also, the other iommu code you pointed me to, was happy to fail, it did
>
On Thu, Jun 21, 2007 at 08:29:34AM +0200, Peter Zijlstra wrote:
> On Wed, 2007-06-20 at 23:11 -0700, Arjan van de Ven wrote:
> > Peter Zijlstra wrote:
> Also, the other iommu code you pointed me to, was happy to fail, it did
> not attempt to use the emergency reserves.
Is the same behavior
On Wed, Jun 20, 2007 at 11:11:05PM -0700, Arjan van de Ven wrote:
> Peter Zijlstra wrote:
> >What I'm saying is that if you do use the reserves, you should ensure
> >the use is bounded. I'm not seeing anything like that.
>
> each mapping takes at most 3 pages
With 3 pages(3 level page table),
On Wed, 2007-06-20 at 23:11 -0700, Arjan van de Ven wrote:
> Peter Zijlstra wrote:
> > What I'm saying is that if you do use the reserves, you should ensure
> > the use is bounded. I'm not seeing anything like that.
>
> each mapping takes at most 3 pages
That is a start, but the thing I'm
Peter Zijlstra wrote:
What I'm saying is that if you do use the reserves, you should ensure
the use is bounded. I'm not seeing anything like that.
each mapping takes at most 3 pages
This is a generic API, who is to ensure some other non-swap device will
not deplete memory and deadlock the
On Wed, 2007-06-20 at 16:03 -0700, Keshavamurthy, Anil S wrote:
> On Wed, Jun 20, 2007 at 10:08:51PM +0200, Peter Zijlstra wrote:
> > On Wed, 2007-06-20 at 12:14 -0700, Arjan van de Ven wrote:
> > > Peter Zijlstra wrote:
> > > > So a reclaim context (kswapd and direct reclaim) set PF_MEMALLOC to
>
On Wed, 2007-06-20 at 16:03 -0700, Keshavamurthy, Anil S wrote:
On Wed, Jun 20, 2007 at 10:08:51PM +0200, Peter Zijlstra wrote:
On Wed, 2007-06-20 at 12:14 -0700, Arjan van de Ven wrote:
Peter Zijlstra wrote:
So a reclaim context (kswapd and direct reclaim) set PF_MEMALLOC to
ensure
Peter Zijlstra wrote:
What I'm saying is that if you do use the reserves, you should ensure
the use is bounded. I'm not seeing anything like that.
each mapping takes at most 3 pages
This is a generic API, who is to ensure some other non-swap device will
not deplete memory and deadlock the
On Wed, 2007-06-20 at 23:11 -0700, Arjan van de Ven wrote:
Peter Zijlstra wrote:
What I'm saying is that if you do use the reserves, you should ensure
the use is bounded. I'm not seeing anything like that.
each mapping takes at most 3 pages
That is a start, but the thing I'm worried most
On Wed, Jun 20, 2007 at 11:11:05PM -0700, Arjan van de Ven wrote:
Peter Zijlstra wrote:
What I'm saying is that if you do use the reserves, you should ensure
the use is bounded. I'm not seeing anything like that.
each mapping takes at most 3 pages
With 3 pages(3 level page table), IOMMU can
On Thu, Jun 21, 2007 at 08:29:34AM +0200, Peter Zijlstra wrote:
On Wed, 2007-06-20 at 23:11 -0700, Arjan van de Ven wrote:
Peter Zijlstra wrote:
Also, the other iommu code you pointed me to, was happy to fail, it did
not attempt to use the emergency reserves.
Is the same behavior acceptable
On Wed, 2007-06-20 at 23:37 -0700, Keshavamurthy, Anil S wrote:
On Thu, Jun 21, 2007 at 08:29:34AM +0200, Peter Zijlstra wrote:
On Wed, 2007-06-20 at 23:11 -0700, Arjan van de Ven wrote:
Peter Zijlstra wrote:
Also, the other iommu code you pointed me to, was happy to fail, it did
not
On Thu, Jun 21, 2007 at 09:13:11AM +0200, Peter Zijlstra wrote:
On Wed, 2007-06-20 at 23:37 -0700, Keshavamurthy, Anil S wrote:
On Thu, Jun 21, 2007 at 08:29:34AM +0200, Peter Zijlstra wrote:
On Wed, 2007-06-20 at 23:11 -0700, Arjan van de Ven wrote:
Peter Zijlstra wrote:
Also, the
On Wed, Jun 20, 2007 at 10:08:51PM +0200, Peter Zijlstra wrote:
> On Wed, 2007-06-20 at 12:14 -0700, Arjan van de Ven wrote:
> > Peter Zijlstra wrote:
> > > So a reclaim context (kswapd and direct reclaim) set PF_MEMALLOC to
> > > ensure they themselves will not block on a memory allocation. And
On Wed, 2007-06-20 at 12:14 -0700, Arjan van de Ven wrote:
> Peter Zijlstra wrote:
> > So a reclaim context (kswapd and direct reclaim) set PF_MEMALLOC to
> > ensure they themselves will not block on a memory allocation. And it is
> > understood that these code paths have a bounded memory
Peter Zijlstra wrote:
So a reclaim context (kswapd and direct reclaim) set PF_MEMALLOC to
ensure they themselves will not block on a memory allocation. And it is
understood that these code paths have a bounded memory footprint.
that's a too simplistic view though; what happens is that kswapd
On Wed, 2007-06-20 at 10:30 -0700, Siddha, Suresh B wrote:
> On Wed, Jun 20, 2007 at 06:03:02AM -0700, Arjan van de Ven wrote:
> > Peter Zijlstra wrote:
> > >
> > >
> > >PF_MEMALLOC as is, is meant to salvage the VM from the typical VM
> > >deadlock.
> >
> > .. and this IS the typical VM
On Wed, Jun 20, 2007 at 06:03:02AM -0700, Arjan van de Ven wrote:
> Peter Zijlstra wrote:
> >
> >
> >PF_MEMALLOC as is, is meant to salvage the VM from the typical VM
> >deadlock.
>
> .. and this IS the typical VM deadlock.. it is your storage driver
> trying to write out a piece of memory on
Peter Zijlstra wrote:
PF_MEMALLOC as is, is meant to salvage the VM from the typical VM
deadlock.
.. and this IS the typical VM deadlock.. it is your storage driver
trying to write out a piece of memory on behalf of the VM, and calls
the iommu to map it, which then needs a bit of
On Tue, 2007-06-19 at 14:37 -0700, Keshavamurthy, Anil S wrote:
> plain text document attachment (intel_iommu_pf_memalloc.patch)
> Intel IOMMU driver needs memory during DMA map calls to setup its internal
> page tables and for other data structures. As we all know that these DMA
> map calls are
On Tue, 2007-06-19 at 14:37 -0700, Keshavamurthy, Anil S wrote:
plain text document attachment (intel_iommu_pf_memalloc.patch)
Intel IOMMU driver needs memory during DMA map calls to setup its internal
page tables and for other data structures. As we all know that these DMA
map calls are
Peter Zijlstra wrote:
PF_MEMALLOC as is, is meant to salvage the VM from the typical VM
deadlock.
.. and this IS the typical VM deadlock.. it is your storage driver
trying to write out a piece of memory on behalf of the VM, and calls
the iommu to map it, which then needs a bit of
On Wed, Jun 20, 2007 at 06:03:02AM -0700, Arjan van de Ven wrote:
Peter Zijlstra wrote:
PF_MEMALLOC as is, is meant to salvage the VM from the typical VM
deadlock.
.. and this IS the typical VM deadlock.. it is your storage driver
trying to write out a piece of memory on behalf of the
On Wed, 2007-06-20 at 10:30 -0700, Siddha, Suresh B wrote:
On Wed, Jun 20, 2007 at 06:03:02AM -0700, Arjan van de Ven wrote:
Peter Zijlstra wrote:
PF_MEMALLOC as is, is meant to salvage the VM from the typical VM
deadlock.
.. and this IS the typical VM deadlock.. it is your
Peter Zijlstra wrote:
So a reclaim context (kswapd and direct reclaim) set PF_MEMALLOC to
ensure they themselves will not block on a memory allocation. And it is
understood that these code paths have a bounded memory footprint.
that's a too simplistic view though; what happens is that kswapd
On Wed, 2007-06-20 at 12:14 -0700, Arjan van de Ven wrote:
Peter Zijlstra wrote:
So a reclaim context (kswapd and direct reclaim) set PF_MEMALLOC to
ensure they themselves will not block on a memory allocation. And it is
understood that these code paths have a bounded memory footprint.
On Wed, Jun 20, 2007 at 10:08:51PM +0200, Peter Zijlstra wrote:
On Wed, 2007-06-20 at 12:14 -0700, Arjan van de Ven wrote:
Peter Zijlstra wrote:
So a reclaim context (kswapd and direct reclaim) set PF_MEMALLOC to
ensure they themselves will not block on a memory allocation. And it is
On Tue, 2007-06-19 at 16:34 -0700, Christoph Lameter wrote:
> On Tue, 19 Jun 2007, Arjan van de Ven wrote:
>
> > > Otherwise you are locked into the use of GFP_ATOMIC.
> >
> > all callers pretty much are either in irq context or with spinlocks held.
> > Good
> > luck. it's also called
On Tue, 19 Jun 2007, Arjan van de Ven wrote:
> > Otherwise you are locked into the use of GFP_ATOMIC.
>
> all callers pretty much are either in irq context or with spinlocks held. Good
> luck. it's also called primarily from the PCI DMA API which doesn't take a
> gfp_t argument in the first
Christoph Lameter wrote:
On Tue, 19 Jun 2007, Keshavamurthy, Anil S wrote:
So far in our test scenario, we were unable to create
any memory allocation failure inside dma map api calls.
All these functions should have gfp_t flags passed to them.
why?
Otherwise you are locked into the use
On Tue, 19 Jun 2007, Keshavamurthy, Anil S wrote:
> So far in our test scenario, we were unable to create
> any memory allocation failure inside dma map api calls.
All these functions should have gfp_t flags passed to them.
Otherwise you are locked into the use of GFP_ATOMIC. If this is a
Intel IOMMU driver needs memory during DMA map calls to setup its internal
page tables and for other data structures. As we all know that these DMA
map calls are mostly called in the interrupt context or with the spinlock
held by the upper level drivers(network/storage drivers), so in order to
Intel IOMMU driver needs memory during DMA map calls to setup its internal
page tables and for other data structures. As we all know that these DMA
map calls are mostly called in the interrupt context or with the spinlock
held by the upper level drivers(network/storage drivers), so in order to
On Tue, 19 Jun 2007, Keshavamurthy, Anil S wrote:
So far in our test scenario, we were unable to create
any memory allocation failure inside dma map api calls.
All these functions should have gfp_t flags passed to them.
Otherwise you are locked into the use of GFP_ATOMIC. If this is a
Christoph Lameter wrote:
On Tue, 19 Jun 2007, Keshavamurthy, Anil S wrote:
So far in our test scenario, we were unable to create
any memory allocation failure inside dma map api calls.
All these functions should have gfp_t flags passed to them.
why?
Otherwise you are locked into the use
On Tue, 19 Jun 2007, Arjan van de Ven wrote:
Otherwise you are locked into the use of GFP_ATOMIC.
all callers pretty much are either in irq context or with spinlocks held. Good
luck. it's also called primarily from the PCI DMA API which doesn't take a
gfp_t argument in the first
On Tue, 2007-06-19 at 16:34 -0700, Christoph Lameter wrote:
On Tue, 19 Jun 2007, Arjan van de Ven wrote:
Otherwise you are locked into the use of GFP_ATOMIC.
all callers pretty much are either in irq context or with spinlocks held.
Good
luck. it's also called primarily from the
40 matches
Mail list logo
