mm->mmap_sem

mm->mmap_sem

[James Simmons]

I noticed that mm_struct has a semaphore in it. How go is it protecting
the memory region? Say we have teh following case. I have a process
that mmaps a chunk of memory and this memory can be sharded with other 
processes. What if the process does a mlock which does a
down(mm->mmap_sem). Now the process goes to sleep and another process
tries to modify the memory region. Will this semaphore protect this
region? In a SMP machine same thing. What kind of protect does this
semaphore provide? Does it prevent other process from doing anything to
the memory. I meant even writing or read it. Thank you.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[Stephen C. Tweedie]

Hi,

On Wed, 22 Sep 1999 17:02:07 -0400 (EDT), James Simmons <jsimmons@edgeglobal.com> said:

> I noticed that mm_struct has a semaphore in it. How go is it protecting
> the memory region? Say we have teh following case. I have a process
> that mmaps a chunk of memory and this memory can be sharded with other 
> processes. What if the process does a mlock which does a
> down(mm->mmap_sem). Now the process goes to sleep and another process
> tries to modify the memory region. 

You have missed the point of the semaphore.  mmap_sem only protects the
vm list against being modified temporarily.  For example, it makes sure
that you don't unmap a VM region while doing a page fault on the same
region.  

An mlock() system call will take the semaphore while it performs the
locking operation and page faults all of the locked data into memory,
but when the mlock call returns, the semaphore will have been released.

> Will this semaphore protect this region? In a SMP machine same
> thing. What kind of protect does this semaphore provide? Does it
> prevent other process from doing anything to the memory. 

No.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[James Simmons]

On Fri, 24 Sep 1999, Stephen C. Tweedie wrote:

> Hi,
> 
> On Wed, 22 Sep 1999 17:02:07 -0400 (EDT), James Simmons <jsimmons@edgeglobal.com> said:
> 
> > I noticed that mm_struct has a semaphore in it. How go is it protecting
> > the memory region? Say we have teh following case. I have a process
> > that mmaps a chunk of memory and this memory can be sharded with other 
> > processes. What if the process does a mlock which does a
> > down(mm->mmap_sem). Now the process goes to sleep and another process
> > tries to modify the memory region. 
> 
> You have missed the point of the semaphore.  mmap_sem only protects the
> vm list against being modified temporarily.  For example, it makes sure
> that you don't unmap a VM region while doing a page fault on the same
> region. 
> An mlock() system call will take the semaphore while it performs the
> locking operation and page faults all of the locked data into memory,
> but when the mlock call returns, the semaphore will have been released.

Does this mean while one process is in the act of mlocking a memory
region another process can actually change the contents of that memory?

> > Will this semaphore protect this region? In a SMP machine same
> > thing. What kind of protect does this semaphore provide? Does it
> > prevent other process from doing anything to the memory. 
> 
> No.

I obtained this idea from do_page_fault. This function is called from a
interrupt when a process actually tries to access memory correct? Even if 
the page does or doesn't exist? I noticed the down(&mm->mmap_sem) in
this function. Does this mean if I had a piece of code somewhere in the
kernel that already did a down(&mm->mmap_sem) on that memory region that 
when do_page_fault would be called that the process trying to access that
page would be put to sleep? Once the semaphore would be released that then
the process would be woken up and then access that memory. If this is not
the case then what would really happen? Thank you for your help by the way
to try and understand this stuff.   


> 
> --Stephen
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://humbolt.geo.uu.nl/Linux-MM/
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[Stephen C. Tweedie]

Hi,

On Fri, 24 Sep 1999 10:59:31 -0400 (EDT), James Simmons
<jsimmons@edgeglobal.com> said:

> Does this mean while one process is in the act of mlocking a memory
> region another process can actually change the contents of that memory?

Yes.  The semaphore only protects against changes to the mmap lists and
page tables.  It does not protect memory itself.  On a multi-processor
machine, the only way the kernel on one CPU can prevent the contents of
a page from being modified by a process on another CPU is to forcibly
revoke all read-write mappings to that page.

>> > Will this semaphore protect this region? In a SMP machine same
>> > thing. What kind of protect does this semaphore provide? Does it
>> > prevent other process from doing anything to the memory. 
>> 
>> No.

> I obtained this idea from do_page_fault. This function is called from a
> interrupt when a process actually tries to access memory correct? 

No, it is only called when a process tries to access memory which is not
currently in the process's page tables.  If the page is already mapped,
then there is no page fault.  Otherwise you'd be doing massive amounts
of kernel work for every byte of data accessed by every process.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[James Simmons]

Hi,

> Yes.  The semaphore only protects against changes to the mmap lists and
> page tables.  It does not protect memory itself.  On a multi-processor
> machine, the only way the kernel on one CPU can prevent the contents of
> a page from being modified by a process on another CPU is to forcibly
> revoke all read-write mappings to that page.

Just out of curoisty how would one revoke all read-write to that page?
I know this would be expensive to do.

Also what does LockPage, TryLockPage(page), and UnlockPage(page) do
exactly? I assume this also doesn't protect the memory contents either.
What I'm guessing at is it protects the page struct itself. If you are
changing the protections on a page you don't want a another process also
attempting to do this. 

> currently in the process's page tables.  If the page is already mapped,
> then there is no page fault.  Otherwise you'd be doing massive amounts
> of kernel work for every byte of data accessed by every process.

Makes sense. I see its a clock algorithm that looks threw the pages and
markes the pages as dirty that have been accessed. Thanks to the link
below I see how thats done. 

Cooperative locking between the framebuffer and accel engine is going to
be alot harder than I though. I was hoping the mmap_sem might do the
trick. I was hoping to find a nice clean way to have it so when the accel
engine is about to become active any access to the framebuffer could just
be reschedule for later execution. You stated that something similar to
sharded memory would work. I toke alook at the code. It looks like all it
does is add a extra layer above ordinary memory handling. How would I
approach this problem with the shared memory method ?

> --Stephen
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://humbolt.geo.uu.nl/Linux-MM/
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[Andrea Arcangeli]

On Fri, 24 Sep 1999, James Simmons wrote:

>Just out of curoisty how would one revoke all read-write to that page?

man mprotect (have a look to PROT_NONE)

>I know this would be expensive to do.

If you don't know how to do that how do you know it's expensive? ;)

But indeed you are right: it's a bit expensive as if the pages are just
allocated you'll have to change all their ptes.

>Also what does LockPage, TryLockPage(page), and UnlockPage(page) do
>exactly? I assume this also doesn't protect the memory contents either.

They have nothing to do with the ptes and vmas and with the userspaces
accesses synchronization.

They only deals with I/O of memory to disk (and with the recycling of
cache/buffer pages to disk: obviously if a page is locked because under
I/O, you can't free it).

>What I'm guessing at is it protects the page struct itself. If you are

It basically synchoronizes the I/O of whole pages from/to disk.

>changing the protections on a page you don't want a another process also
>attempting to do this. 

That is preserved using the mmap_sem as the mmap_sem serializes the
ptes/vmas writes. (mprotect grab the mmap sem of course)

>> then there is no page fault.  Otherwise you'd be doing massive amounts
>> of kernel work for every byte of data accessed by every process.
>
>Makes sense. I see its a clock algorithm that looks threw the pages and
>markes the pages as dirty that have been accessed. Thanks to the link

What Stephen wanted to tell is that if you have the pages just mapped and
allocated in the process space (pte_present(pte) == 1), then no page fault
will happen by touching such pages.

Only the _first_ time you'll touch a (not mlocked) anonymous mapping
(malloced region) you'll trigger a page-fault to effectively allocate and 
then map a zeroed page for the process.

Andrea

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[James Simmons]

On Sat, 25 Sep 1999, Andrea Arcangeli wrote:

> On Fri, 24 Sep 1999, James Simmons wrote:
> 
> >Just out of curoisty how would one revoke all read-write to that page?
> 
> man mprotect (have a look to PROT_NONE)
> 
> >I know this would be expensive to do.
> 
> If you don't know how to do that how do you know it's expensive? ;)

Well I kind of figured I would have to do what mprotects does. I just
needed someone to say yes mprotect is the way to not allow processes
physical access to a memory region. I just wanted to make sure I was
right. Also I don't want the process to be sent a SIGSEGV. I just want to
put it to sleep for a period of time if it access such a region.

> But indeed you are right: it's a bit expensive as if the pages are just
> allocated you'll have to change all their ptes.

Like mprotect does. How does this compare to unmmaping a large memory
region and putting a process to sleep in a no_page_fault routine.

Is their any way to do cooperative locking kernel side between two memory
regions? If one is being access you can't physically access the other. I
just want to process to sleep not kill it if it attempts this.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[Andrea Arcangeli]

On Sat, 25 Sep 1999, James Simmons wrote:

>Is their any way to do cooperative locking kernel side between two memory
>regions? If one is being access you can't physically access the other. I
>just want to process to sleep not kill it if it attempts this.

Ah ok.

So just add a spinlock in userspace. As test_and_set_bit works in
userspace also the spinlock will work fine in userspace.

Just make sure to always have the lock held before touching the memory
region you want to serialize the accesses to.

You need to add the locking into userspace.

Andrea

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[James Simmons]

> On Sat, 25 Sep 1999, James Simmons wrote:
> 
> >Is their any way to do cooperative locking kernel side between two memory
> >regions? If one is being access you can't physically access the other. I
> >just want to process to sleep not kill it if it attempts this.
> 
> Ah ok.

To be exactly I'm trying to do cooperative locking between a mmaping of
the accel region of /dev/gfx and the framebuffer region of /dev/fb. I
notice that after mmapping the kernel can no long control access to the
memory regions. So I need to block any process from accessing the
framebuffer while the accel engine is running. Since many low end cards
lock if you access the framebuffer and accel engine at the same time. 
Note /dev/fb and /dev/gfx both can be opened by different processes.

> So just add a spinlock in userspace. As test_and_set_bit works in
> userspace also the spinlock will work fine in userspace.

Really. Thats a good idea.

> Just make sure to always have the lock held before touching the memory
> region you want to serialize the accesses to.
> 
> You need to add the locking into userspace.

Will this work for mmap regions as well?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[Andrea Arcangeli]

On Sat, 25 Sep 1999, James Simmons wrote:

>framebuffer while the accel engine is running. Since many low end cards
>lock if you access the framebuffer and accel engine at the same time. 

I see your point.

>Note /dev/fb and /dev/gfx both can be opened by different processes.

If they are two threads and so if they are sharing the same process MM,
you can simply alloc the spinlock in the .data segment (trivial global
variable).

If the two process are not threads (so if they are not sharing the same
MM) then alloc the spinlock (or in general the memory you want to use as
an atomic lock) in a shared shm segment.

>Will this work for mmap regions as well?

Sure: you only need to always acquire the spinlock before accessing the
region of virtual memory. It doesn't metter which kind of memory you are
going to access.

Andrea

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[Neil Conway]

James Simmons wrote:
> 
> I obtained this idea from do_page_fault. This function is called from a
> interrupt when a process actually tries to access memory correct? Even if
> the page does or doesn't exist? 

That's the bit that's tripping you up then.  No page-fault will occur in
general if the page has already been used and hasn't been swapped out
etc.  How bad would performance be if every access to every page caused
an interrupt?

Neil
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[Marcus Sundberg]

James Simmons wrote:
> To be exactly I'm trying to do cooperative locking between a mmaping of
> the accel region of /dev/gfx and the framebuffer region of /dev/fb. I
> notice that after mmapping the kernel can no long control access to the
> memory regions. So I need to block any process from accessing the
> framebuffer while the accel engine is running. Since many low end cards
> lock if you access the framebuffer and accel engine at the same time.

No, you are trying to do _mandatory_ locking enforced by the kernel.
For cooperative locking on sane GFX hardware a userspace spinlock is
indeed all that is required, but for the broken hardware you are talking
about kernel locking would be required.

This means that when the accel engine is initiated you must unmap all
pages of the framebuffer (8k pages on modern cards), install a no-page
handler and flush the TLBs of all processors. If accel commands are
batched, applications do accesses in an intelligent way, and the
framebuffer is only re-mapped when it is actually accessed you might
get usable performance.

Still, I'm not sure it's worth the trouble. Personally I'd rather buy
decent hardware or only run trusted applications than take this 
performance hit.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[Stephen C. Tweedie]

Hi,

On Sat, 25 Sep 1999 12:50:57 -0400 (EDT), James Simmons
<jsimmons@edgeglobal.com> said:

> Is their any way to do cooperative locking kernel side between two
> memory regions? If one is being access you can't physically access the
> other. I just want to process to sleep not kill it if it attempts
> this.

Sure.  You can always use a semaphore or spinlock to do cooperative
locking.  Physically preventing the access is what is expensive (far,
far, far too expensive to be worthwhile doing it frequently if your
driver requires that).

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[Stephen C. Tweedie]

Hi,

On Sat, 25 Sep 1999 21:19:59 -0400 (EDT), James Simmons
<jsimmons@edgeglobal.com> said:

> To be exactly I'm trying to do cooperative locking between a mmaping of
> the accel region of /dev/gfx and the framebuffer region of /dev/fb. 

I thought you might be.  Look at the DRI (XI's direct rendering
infrastructure): they implement a cooperative locking mechanism which
optimises the fast case (current locker was also the last holder of the
lock) not to require a syscall at all.

Using any form of physical memory protection will be too slow.

> I notice that after mmapping the kernel can no long control access to
> the memory regions. So I need to block any process from accessing the
> framebuffer while the accel engine is running. Since many low end
> cards lock if you access the framebuffer and accel engine at the same
> time.

I know.  The hardware sucks.  There is no fast way to deal with it.  The
closest you might get to it is ia32 segmentation, but we don't support
that in the kernel and never will.

> Will this work for mmap regions as well?

We're talking about _cooperative_ locking.  We are relying on the
applications to do the correct locking, so sure, if the application
takes a lock before accessing an mmaped region, that will work too.

You still don't prevent a rogue application from locking the graphics
adapter. 

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[James Simmons]

> No, you are trying to do _mandatory_ locking enforced by the kernel.
> For cooperative locking on sane GFX hardware a userspace spinlock is
> indeed all that is required, but for the broken hardware you are talking
> about kernel locking would be required.

What are all the broken cards out their? I was reading my old Matrox
Millenium I docs and even that card supports similutaneous access to 
the accel engine and framebuffer. If the number of cards that are that
broken are small then I just will not support them.

> This means that when the accel engine is initiated you must unmap all
> pages of the framebuffer (8k pages on modern cards), install a no-page
> handler and flush the TLBs of all processors.

All the processors!! Thats really bad.



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[James Simmons]

> Hi,
> 
> On Sat, 25 Sep 1999 21:19:59 -0400 (EDT), James Simmons
> <jsimmons@edgeglobal.com> said:
> 
> > To be exactly I'm trying to do cooperative locking between a mmaping of
> > the accel region of /dev/gfx and the framebuffer region of /dev/fb. 
> 
> I thought you might be.  Look at the DRI (XI's direct rendering
> infrastructure): they implement a cooperative locking mechanism which
> optimises the fast case (current locker was also the last holder of the
> lock) not to require a syscall at all.

Already am peeking under the hood.

> Using any form of physical memory protection will be too slow.

Agree. 

> > I notice that after mmapping the kernel can no long control access to
> > the memory regions. So I need to block any process from accessing the
> > framebuffer while the accel engine is running. Since many low end
> > cards lock if you access the framebuffer and accel engine at the same
> > time.
> 
> I know.  The hardware sucks.  There is no fast way to deal with it.  The
> closest you might get to it is ia32 segmentation, but we don't support
> that in the kernel and never will.

Well if the number of cards that are broken this bad are small then I will
just not support such cards. If simulatenous access just screws up the
screen well that will not count. As long as crumy hardware is not allowed
to lock the machine.

> You still don't prevent a rogue application from locking the graphics
> adapter. 

Yuck. I rather not support that kind of hardware if that type of hardware 
is small in numbers. 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[Stephen C. Tweedie]

Hi,

On Mon, 27 Sep 1999 15:31:28 -0400 (EDT), James Simmons
<jsimmons@edgeglobal.com> said:

>> No, you are trying to do _mandatory_ locking enforced by the kernel.
>> For cooperative locking on sane GFX hardware a userspace spinlock is
>> indeed all that is required, but for the broken hardware you are talking
>> about kernel locking would be required.

> What are all the broken cards out their? I was reading my old Matrox
> Millenium I docs and even that card supports similutaneous access to 
> the accel engine and framebuffer. If the number of cards that are that
> broken are small then I just will not support them.

I think that there's a large number of them.  The XI and XFree86 folk
would probably know which ones exactly.

>> This means that when the accel engine is initiated you must unmap all
>> pages of the framebuffer (8k pages on modern cards), install a no-page
>> handler and flush the TLBs of all processors.

> All the processors!! Thats really bad.

Yes.  That is the specific case which makes this impractical to do in
software.  It would be bad enough on one CPU, but having to do it on all
requires sending inter-CPU interrupts, and that is simply too slow for a
fast graphics engine.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[James Simmons]

On Thu, 30 Sep 1999, Stephen C. Tweedie wrote:

> Hi,
> 
> On Mon, 27 Sep 1999 15:31:28 -0400 (EDT), James Simmons
> <jsimmons@edgeglobal.com> said:
> 
> > What are all the broken cards out their? I was reading my old Matrox
> > Millenium I docs and even that card supports similutaneous access to 
> > the accel engine and framebuffer. If the number of cards that are that
> > broken are small then I just will not support them.
> 
> I think that there's a large number of them.  The XI and XFree86 folk
> would probably know which ones exactly.

Yikes. I think the best solution is to just put the process that owns
the framebuffer to be put to sleep just before accel engine access. Wake
it up once its done. Some fancy scheduling tricks should do it. I have it
setup now that accels used internal in the kernel to speed up console
rendering will not work when /dev/fb is mmapped. Also I have set it up so
only one process can open /dev/fb at a time. This makes life much easier.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[Benjamin C.R. LaHaise]

On Wed, 29 Sep 1999, James Simmons wrote:

> On Thu, 30 Sep 1999, Stephen C. Tweedie wrote:
> 
> > Hi,
> > 
> > On Mon, 27 Sep 1999 15:31:28 -0400 (EDT), James Simmons
> > <jsimmons@edgeglobal.com> said:
> > 
> > > What are all the broken cards out their? I was reading my old Matrox
> > > Millenium I docs and even that card supports similutaneous access to 
> > > the accel engine and framebuffer. If the number of cards that are that
> > > broken are small then I just will not support them.
> > 
> > I think that there's a large number of them.  The XI and XFree86 folk
> > would probably know which ones exactly.
> 
> Yikes. I think the best solution is to just put the process that owns
> the framebuffer to be put to sleep just before accel engine access. Wake
> it up once its done. Some fancy scheduling tricks should do it. I have it
> setup now that accels used internal in the kernel to speed up console
> rendering will not work when /dev/fb is mmapped. Also I have set it up so
> only one process can open /dev/fb at a time. This makes life much easier.

No, same problem.  You can't put a process to sleep without
inter-processor interrupts on smp if its not running currently.  You can't
allow the kernel to touch the frame buffer if the user is using the
accelerator or vice-versa.  Have an ioctl to lock the kernel out from
updating, and only unlock it from user space when there's no activity for
a while.

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[Stephen C. Tweedie]

Hi,

On Wed, 29 Sep 1999 20:17:01 -0400 (EDT), James Simmons
<jsimmons@edgeglobal.com> said:

> Yikes. I think the best solution is to just put the process that owns
> the framebuffer to be put to sleep just before accel engine access. Wake
> it up once its done. 

On SMP, that still requires inter-CPU interrupts to all processors in
the worst case, as the process may already be running elsewhere.  It
doesn't get around the IPI cost.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[James Simmons]

> No, same problem.  You can't put a process to sleep without
> inter-processor interrupts on smp if its not running currently.

So only putting the current process to sleep doesn't cost anything. 
Putting another process to sleep does cost. I see this as being alot less
costly then the unmap the framebuffer and put the process to sleep on page
fault just before you access the accel engine solution. I though putting
another process to sleep would be easy. Just remove it from the run queue
and place it in the wait_queue. Mark the process as UNINTERUPPITABLE. Once
finished with the accel engine just remove it from the wait_queue and
place on the run_queue again. What am I missing?

Here is another question since its very expensive putting another process 
to sleep. If the process owns both the accel engine and framebuffer then I
should be able to put the process to sleep while the accel engine is
running? Since the process is asleep it can't acces the framebuffer but
the accel engine is still running on the card.    

  Another question. Do the cards lock when you access any part of the
framebuffer and the accel engine or do the cards lock when you access
the a part of the framebuffer which at the same time is being modified by
the accel engine? If this is the case I was thinking about this possible
solution. You could have ioctl call to /dev/gfx where you would specify a
window in the framebuffer you want. That area of the framebuffer would be
removed from process address space owning the framebuffer and added to the
process address space that owns /dev/gfx. This way you could have a
application open /dev/gfx in X windows it would  actually grab a piece of
the framebuffer for its self. The X server could not access this memory
region. Of course the X server would have to handle the seg fault
gracefully. The application could then write to the framebuffer directly.
Also the application could send accel commands to this region. Now since
both regions are controled by the same process we can put to sleep that
process until the accel engine is done.         

> You can't
> allow the kernel to touch the frame buffer if the user is using the
> accelerator or vice-versa.  Have an ioctl to lock the kernel out from
> updating, and only unlock it from user space when there's no activity for
> a while.

  These are mmapped regions. So locking out the kernel will not help. You
have to prevent userland from accessing the memory region to prevent the
machine from locking. 


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[Benjamin C.R. LaHaise]

On Thu, 30 Sep 1999, James Simmons wrote:

> > No, same problem.  You can't put a process to sleep without
> > inter-processor interrupts on smp if its not running currently.
> 
> So only putting the current process to sleep doesn't cost anything. 
> Putting another process to sleep does cost. I see this as being alot less
> costly then the unmap the framebuffer and put the process to sleep on page
> fault just before you access the accel engine solution. I though putting
> another process to sleep would be easy. Just remove it from the run queue
> and place it in the wait_queue. Mark the process as UNINTERUPPITABLE. Once
> finished with the accel engine just remove it from the wait_queue and
> place on the run_queue again. What am I missing?

What if it's running on another CPU?  Then you have to do the same thing
that is done for tlb shootdown -- cross cpu synchronization is expensive!

> Here is another question since its very expensive putting another process 
> to sleep. If the process owns both the accel engine and framebuffer then I
> should be able to put the process to sleep while the accel engine is
> running? Since the process is asleep it can't acces the framebuffer but
> the accel engine is still running on the card.    

Oh gawd...  How much does the kernel know about the accelerator?
Something to consider is that the 'right' solution might be to make the
kernel pass console handling to a user task -- have you ever considered
that?

>   These are mmapped regions. So locking out the kernel will not help. You
> have to prevent userland from accessing the memory region to prevent the
> machine from locking. 

And the performance-correct way to do this is with a cooperative lock that
is *not part* of the mmap'd region.  This is where the difference between
personal computers and servers becomes apparent: with a personal computer,
you cannot protect the system against the local user in all cases because
the cost is too high.  This is one of those cases. 

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mm->mmap_sem

[James Simmons]

> > Here is another question since its very expensive putting another process 
> > to sleep. If the process owns both the accel engine and framebuffer then I
> > should be able to put the process to sleep while the accel engine is
> > running? Since the process is asleep it can't acces the framebuffer but
> > the accel engine is still running on the card.    
> 
> Oh gawd...  How much does the kernel know about the accelerator?

Its a memory region thats mmap to userspace. Thats all it knows. By the
way what I suggested above would work.

> Something to consider is that the 'right' solution might be to make the
> kernel pass console handling to a user task -- have you ever considered
> that?

Uhm. No. I don't think that will work for what I want.

> >   These are mmapped regions. So locking out the kernel will not help. You
> > have to prevent userland from accessing the memory region to prevent the
> > machine from locking. 
> 
> And the performance-correct way to do this is with a cooperative lock that
> is *not part* of the mmap'd region. 

That still doesn't prevent a rogue aplication from locking the machine on
purpose. A application could just ignore the locks.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/