search for: pg_foreign

Xenlinux uses a special architecture-dependent bit in the page table, called PG_arch_1 to indicate that a page is "foreign" (PG_foreign). It also apparently uses it to determine if a page is pinned (PG_pinned). Linux/ia64 (and apparently Linux/ppc and Linux/ppc64) use the PG_arch_1 bit for other purposes. On Linux/ia64, it is used to determine if the instruction cache needs to be flushed (e.g. if writing data into code pages). A...

...x86-specific > > code. But one is in netback_init(). > > That thread seems to already have a solution. Has anybody run it past > Linux MM people? (Adding xen-devel to CC for greater exposure.) If by "solution" you mean that Keir could change Xenlinux to add a new "PG_foreign" bit and change Xenlinux/x86 (and netback) to use that bit rather than PG_arch_1, I agree. Comments, Keir (or others)? Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...; ( (void (*) (struct page *)) page_private((page)) ) > Hi, Isaku, (page)->mapping is used to keep special destructor since that foreign page needs to be freed differently as normal linux pages, as you see in foreign_page.h. Your hack only ensures the check. Agree right way to go to propose PG_foreign upstream. Thanks, Kevin _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel

...ge)) ) >> > >> >> Hi, Isaku, >> (page)->mapping is used to keep special destructor since that >foreign page needs to be freed differently as normal linux pages, as you >see in foreign_page.h. Your hack only ensures the check. Agree right >way to go to propose PG_foreign upstream. > >A special destructor is kept in page->private by set_page_private() and >get by page_private(). page->private is unsigned long so that it can >hold pointer value. > >They are just defined as >#define page_private(page) ((page)->private) >#d...

While I have a patch queued to address related issues in intel-agp, a quick scan of the Linux tree seems to reveal several more cases where assumptions are being made on GFP_DMA{,32} allocations - either the result (even properly passed through virt_to_bus()) is put into hardware registers (with no guarantee that it fits the width required by those registers or fields thereof), or page-crossing

Hi Keir: These two patches remove the need for netloop by performing the copying in netback and only if it is necessary. The rationale is that most packets will be processed without delay allowing them to be freed without copying at all. So instead of copying every packet destined to dom0 we''ll only copy those that linger longer than a specified amount of time (currently 0.5s). As it