Re: [PATCH] New phys_addr() syscall
Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Tue, 21 Jul 1998 18:57:09 +1000
Raul Miller writes:
> Richard Gooch <Richard.Gooch@atnf.CSIRO.AU> wrote:
> > Raul Miller writes:
> > > Albert D. Cahalan <acahalan@cs.uml.edu> wrote:
> > > > There were plans to make mlock() available to normal users for
> > > > cryptographic purposes. There would be a quota to protect the
> > > > machine. If a user (or group of users) can get 1/32 of the pages
> > > > below 16 MB, then the system can not allocate 128 kB for DMA.
> > >
> > > You'll eventually want to allow memory locked with this variation of
> > > mlock to be migrated out of the DMA region (to deal with fragmentation
> > > issues).
> >
> > That may present an unacceptable cost to a RT application. Copying a
> > page can easily take 100 microseconds. If Linux ever has the ability
> > to pin a RT process to a CPU, that process should never be delayed if
> > it doesn't ask to I/O (assuming it's mlock(2)ed all it's pages).
>
> I thought you needed special priviledge to do RT? I thought Albert
> Cahalan was speaking of allowing unpriviledged mlocks?
Yes, you need privileges to do RT. But that's not the point. The point
I was making is that you can't (or shouldn't) change mlock(2)
semantics to mean "don't page to disc but maybe move physical page",
because that would foul-up an RT process.
Therefore mlock(2) pins a virtual page to a physical page, period. Now
we can say, "hey, I can do a hack with mlock(2), iopl(2), virt->phys
translations and other tricks to implement userspace drivers".
> > Moving to another physical page is contrary to the spirit of mlock(2),
> > IMO.
>
> I suppose an alternative, at least for the unpriviledged mlock,
> would be to never allow memory from the low 16M (except on machines
> with 16M or less).
This may be a good idea in any case, whether or not virt->phys
translations are made available.
Regards,
Richard....
-
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.altern.org/andrebalsa/doc/lkml-faq.html