Christoph Lameter wrote: > The same can be done using the virtual->physical mappings that exist on > many platforms for the kernel address space (ia64 dynamically calculates > those, x86_64 uses a page table with 2M pages for mapping the kernel). Yes, that's basically what Xen does - there's a nonlinear mapping from kernel virtual to machine pages (and usermode pages are put through the same transformation before being mapped). > The > problem is that the 1-1 mapping between physical and virtual addresses > will have to be (at least partially) sacrificed which may lead to > complications with DMA devices. > Yes, any driver which expects contigious kernel pages to be physically contigious will be sorely disappointed. This isn't too hard to deal with (since such drivers are often buggy anyway, making poor assumptions about the relationship between physical addresses and bus addresses). An IOMMU could help as well. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- References:
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- From: Andrew Morton <[email protected]>
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- From: Christoph Lameter <[email protected]>
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- From: Andrew Morton <[email protected]>
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- From: Christoph Lameter <[email protected]>
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- From: Andrew Morton <[email protected]>
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- From: Christoph Lameter <[email protected]>
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- From: Andrew Morton <[email protected]>
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- From: Christoph Lameter <[email protected]>
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- From: Andrew Morton <[email protected]>
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- From: Christoph Lameter <[email protected]>
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- From: [email protected] (Mel Gorman)
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- From: Christoph Lameter <[email protected]>
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- From: Mel Gorman <[email protected]>
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- From: Christoph Lameter <[email protected]>
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- From: Jeremy Fitzhardinge <[email protected]>
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- From: Christoph Lameter <[email protected]>
- Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- Prev by Date: Re: Kernel 2.6 SMP very slow with ServerWorks LE Chipset
- Next by Date: [PATCH 001/001] crypto: add sha384 hmac and sha512 hmac tests to tcrypt in 2.6.19 kernel
- Previous by thread: Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- Next by thread: Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
- Index(es):