Re: [GSOC] System V IPC in userspace week3 report

["Samuel J. Greear" <sjg@xxxxxxxxxxxx>]

--089e01493bf4ad897f04e0f45b50
Content-Type: text/plain; charset=ISO-8859-1

Performance is only one goal of this project and system call overhead is
only a single aspect of performance. There are other objectives here, to be
able to use sysv services inside of a jail w/o exposing the global kernel
sysv resources to that jail. To be able to compartmentalize sysv resource
usage. To make it easier to ration out / enforce a quota on sysv ipc
resources for individual consumers.

Implementing semaphores and message queues on top of sysv shm would
entirely defeat large parts of the purpose of this project.

Look harder at mmap(2).

Sam


On Sun, Jul 7, 2013 at 5:08 PM, grigore larisa <larisagrigore@gmail.com>wrote:

> Hello,
>
> This week I have done the following things:
> - extended my tests in order to support multiple clients
> - implemented a hashtable in order to find easy a client using its pid. It
> can be used to verify if a client is already connected.
> - resolved some bugs related to locking and polling
> - investigated the impact of implementing shared memory in userland
>
> These days I've studied how shm is implemented in kernel and how I could
> move it in userland. Moving it in userland means moving only data
> associated with each segment and permission checks. The operation of
> allocating or mapping a segment must still be done in kernel.
>
> As far as I understand, the project purpose is to implement in userland
> those parts of sysv ipc resources that help big ipc consumers to have
> better performance. I think this can be a good idea for semaphores and
> message queues, where some syscalls can be avoided. In shared memory case,
> I don't see that possible.
> For shmget call, two messages must be sent (to the daemon and back to the
> client) plus a syscall made by daemon when it must allocate a segment (when
> some client need a shared memory resource that doesn't exist, such a
> segment is allocated). For shmclt, one or two messages must be sent,
> depending one the command. Maybe, only in shmat and shmdt I can avoid to
> send messages to the daemon if some data are kept by the driver (number of
> clients that use the resource for example) but the client will still do a
> syscall to map/detach the shared memory object (as in the current
> implementation).
>
> In semaphores and message queues case, even if obtaining/controlling
> (*get, *ctl) the object is more expensive than the kernel implementation
> because of the communication with the daemon, semop()/msgget()/msgrcv()
> (that are more frequently used) in userland are less expensive because they
> do operations on shared memory.
>
> I think is a better idea to implement userland semaphores and queues on
> top of sysv shm already existing. What do you think about this?
>
> Larisa
>

--089e01493bf4ad897f04e0f45b50
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Performance is only one goal of this project and system ca=
ll overhead is only a single aspect of performance. There are other objecti=
ves here, to be able to use sysv services inside of a jail w/o exposing the=
 global kernel sysv resources to that jail. To be able to compartmentalize =
sysv resource usage. To make it easier to ration out / enforce a quota on s=
ysv ipc resources for individual consumers.<div>
<br></div><div style>Implementing semaphores and message queues on top of s=
ysv shm would entirely defeat large parts of the purpose of this project.</=
div><div style><br></div><div style>Look harder at mmap(2).</div><div style=
>
<br></div><div style>Sam</div></div><div class=3D"gmail_extra"><br><br><div=
 class=3D"gmail_quote">On Sun, Jul 7, 2013 at 5:08 PM, grigore larisa <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:larisagrigore@gmail.com"; target=3D"_blan=
k">larisagrigore@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello,<div><br></div><div>T=
his week I have done the following things:</div><div>- extended my tests in=
 order to support multiple clients</div>
<div>- implemented a hashtable in order to find easy a client using its pid=
. It can be used to verify if a client is already connected.</div>
<div>- resolved some bugs related to locking and polling</div><div>- invest=
igated the impact of implementing shared memory in userland</div><div><br><=
/div><div><div style=3D"font-family:arial,sans-serif;font-size:13px">
These days I&#39;ve studied how shm is implemented in kernel and how I coul=
d move it in userland. Moving it in userland means moving only data associa=
ted with each segment and permission checks. The operation of allocating or=
 mapping a segment must still be done in kernel.</div>

<div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div><div s=
tyle=3D"font-family:arial,sans-serif;font-size:13px">As far as I understand=
, the project purpose is to implement in userland those parts of sysv ipc r=
esources that help big ipc consumers to have better performance. I think th=
is can be a good idea for semaphores and message queues, where some syscall=
s can be avoided. In shared memory case, I don&#39;t see that possible.</di=
v>

<div style=3D"font-family:arial,sans-serif;font-size:13px">For shmget call,=
 two messages must be sent (to the daemon and back to the client) plus a sy=
scall made by daemon when it must allocate a segment (when some client need=
 a shared memory resource that doesn&#39;t exist, such a segment is allocat=
ed). For shmclt, one or two messages must be sent, depending one the comman=
d. Maybe, only in shmat and shmdt I can avoid to send messages to the daemo=
n if some data are kept by the driver (number of clients that use the resou=
rce for example) but the client will still do a syscall to map/detach the s=
hared memory object (as in the current implementation).</div>

<div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div><div s=
tyle=3D"font-family:arial,sans-serif;font-size:13px">In semaphores and mess=
age queues case, even if obtaining/controlling (*get, *ctl) the object is m=
ore expensive than the kernel implementation because of the communication w=
ith the daemon, semop()/msgget()/msgrcv() (that are more frequently=A0used)=
 in userland are less expensive because they do operations on shared memory=
.</div>

<div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div><div s=
tyle=3D"font-family:arial,sans-serif;font-size:13px">I think is a better id=
ea to implement userland semaphores and queues on top of sysv shm already e=
xisting. What do you think about this?</div>
<span class=3D"HOEnZb"><font color=3D"#888888">
<div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div><div s=
tyle=3D"font-family:arial,sans-serif;font-size:13px">Larisa</div></font></s=
pan></div></div>
</blockquote></div><br></div>

--089e01493bf4ad897f04e0f45b50--