On Sun, Dec 27, 2015 at 02:10:47PM +0200, Tanu Kaskinen wrote:
> On Sat, 2015-12-26 at 21:51 +0200, Ahmed S. Darwish wrote:
...
> >
> > > If I understand vacuuming correctly, it means telling the kernel that
> > > the memory in unused memblocks probably won't be used any time soon,
> > > and that we also don't care about the current data in them, so the
> > > kernel can optimize memory usage accordingly. pa_core_maybe_vacuum()
> > > only vacuums when there's no audio moving in the system.
> >
> > That's what I understood from the code, yes.
> >
> > > When you
> > > change rw_mempools to be created separately for each client, I think it
> > > would make sense to vacuum the per-client mempool every time the client
> > > stops streaming. That logic could live inside the native protocol, so
> > > the core wouldn't have to know about rw_mempools.
> > >
> >
> > I see, makes sense.
> >
> > I've implemented this by vacuuming upon receiving CORK_PLAYBACK_STREAM
> > or CORK_RECORD_STREAM. Hopefully this is the right approach.
>
> Do you take into account the case where there are two streams and only
> one of them stops? I think vacuuming should be done only when the state
> changes from "some streams active" to "no streams active".
Hmm, my knowledge is still limited in this area. I thought
there's a one-to-one relation between a per-client connection
and a stream.
After some thinking, I guess this can happen when one client
creates both a playback stream and a recording one?
>
> In addition to corking, the active -> not active transition can also
> happen when the client tears down a stream.
>
PA_COMMAND_FLUSH_{PLAYBACK,RECORDING}`_STREAM?
Thanks a lot,
--
Darwish
http://darwish.chasingpointers.com
