On Sunday 19 October 2008 06:31, Linus Torvalds wrote: > On Sat, 18 Oct 2008, Keith Packard wrote: > > The basic plan is to have four new functions (yes, I'm making up names > > here): > > > > struct io_mapping *io_reserve_pci_resource(struct pci_dev *dev, > > int bar, > > int prot); > > void io_mapping_free(struct io_mapping *mapping); > > > > void *io_map_atomic(struct io_mapping *mapping, unsigned long pfn); > > void io_unmap_atomic(struct io_mapping *mapping, unsigned long pfn); > > The important thing is that mappings need to be per-CPU, so the above may > work, but only if it's designed so that "io_reserve_pci_resource()" will > actually reserve space for 'nr_possible_cpu' page mappings, and then the > "io_[un]map_atomic()" functions do per-CPU mappings. > > Anything else is a disaster, because anything else implies TLB shootdown.
TLB shootdown need only be implied if the behaviour required is to unmap the virtual address *and* cause any other CPU that subsequently touches it to fault. For kva, that would be a bug anyway (use after free). The only thing it implies is that a TLB shootdown happens at some point before the address get reused. Still, it's always going to be faster than a global mapping, if done properly. I was thinking about doing a vmap_atomic thing generically in the vmap layer... why exactly do we need the FIXMAP stuff for it? ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
