Re: (XFree86) mmap of /proc/XXX/mem
Egbert Eich (eich@hilbert.ikp.physik.tu-darmstadt.de)
Sat, 4 Dec 1999 01:42:50 +0100 (MET)
Pavel Machek writes:
> Hi!
>
> > > > Yes, but how? We need a solution otherwise we won't be able to
> > > > use the vm86 mode even on Intel. The emulator makes everything
> > > > even slower.
> > >
> > > Check dosemu. The _real_ problem with /proc/<pid>/mem is that it needs
> > > very different behaviour in different parts of process address space. Just
> > > aliasing every page and hoping that extra reference will save your day is
> > > _very_ bad idea - behaviour of pages on swapout, etc. is determined by
> > > vma, not by reference in page table. We _might_ go for /proc/<pid>/object/
> > > a-la Slowlaris, and that might be made mmap'able, but that's a separate
> > > story. And IMO an overkill.
> > >
> > > Dosemu does aliasing in very similar situation. Check how it's done.
> >
> > I don't think dosemu saves my day. It needs just _one_ 1Mb real mode image.
> > I know how to do that, too. No problem. As I tried to explain in
> > my original posting I need _several_ 1Mb images: one for each graphics
> > card. I need to swap them _fast_ without moving around large
> > chunks of memory.
> > When another card is selected I could in prinicple copy out the
> > 1 Meg image of the one previously selected and then copy in the
> > 1 Meg of the newly selected one. But this is _slow_ compared to
> > just calling munmap()/mmap() to swap cards. If I only did that
> > for initialization it's OK. But if I want to do it while the Xserver
> > is running and in Operating state (ie for updating pallete or
> > whatever else needs to be done) it is painfully slow.
> > With mmap() /proc/XXX/mem I can keep all images set up in virtual
> > address space and only map in the one I need.
>
> Why don't you just prepare 5 files, 1Mega each, and mmap them when you
> need it? What am I missing?
This was suggested, already. I could do this in principle.
I wont be able to map the V_RAM into each image and "swap" this
in with the rest any more.
Egbert.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/