Carlos O'Donell wrote on Tue, Dec 14, 2021 at 11:07:42AM -0500:
> > So I guess we're just chasing after artifacts from the allocator, and
> > it'll be hard to tell which it is when I happen to see pipewire-pulse
> > with high memory later on...
>
> It can be difficult to tell the difference
On 12/14/21 07:08, Dominique Martinet wrote:
> I've double-checked with traces in load_spa_handle/unref_handle and it
> is all free()d as soon as the client disconnects, so there's no reason
> the memory would still be used... And I think we're just looking at some
> malloc optimisation not
Wim Taymans wrote on Tue, Dec 14, 2021 at 09:09:30AM +0100:
> I can get it as high as that too but then it stays there and doesn't really
> grow anymore so it does not seem like
> it's leaking. Maybe it's the way things are done, there is a lot of ldopen
> and memfd/mmap.
Right, I've had a look
On Tue, Dec 14, 2021 at 09:09:30AM +0100, Wim Taymans wrote:
> I can get it as high as that too but then it stays there and doesn't really
> grow anymore so it does not seem like
> it's leaking. Maybe it's the way things are done, there is a lot of ldopen
> and memfd/mmap.
This doesn't sound
I can get it as high as that too but then it stays there and doesn't really
grow anymore so it does not seem like
it's leaking. Maybe it's the way things are done, there is a lot of ldopen
and memfd/mmap.
Wim
On Mon, Dec 13, 2021 at 11:42 PM Dominique Martinet
wrote:
> Wim Taymans wrote on
Wim Taymans wrote on Mon, Dec 13, 2021 at 09:22:42AM +0100:
> There was a leak in 0.3.40 that could explain this, see
> https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1840
>
> Upcoming 0.3.41 will have this fixed. At least I can't reproduce this
> anymore with the test you posted
There was a leak in 0.3.40 that could explain this, see
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1840
Upcoming 0.3.41 will have this fixed. At least I can't reproduce this
anymore with the test you posted below.
Wim
On Sun, Dec 12, 2021 at 12:49 PM Dominique Martinet
wrote:
>
Fabio Valentini wrote on Sun, Dec 12, 2021 at 12:25:11PM +0100:
> > on my laptop, /usr/bin/pipewire uses 56M RSS, 5M SHR,
> > but/usr/bin/pipewire-pulse uses 347M RSS, 4M SHR.
> > 56M is okeyish, but 347M seems a lot. I think firefox is going
> > through pipewire-pulse, so that interface might
On Sun, Dec 12, 2021 at 12:25:11PM +0100, Fabio Valentini wrote:
> On Sat, Dec 11, 2021 at 6:46 PM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > Hi,
> >
> > on my laptop, /usr/bin/pipewire uses 56M RSS, 5M SHR,
> > but/usr/bin/pipewire-pulse uses 347M RSS, 4M SHR.
> > 56M is okeyish, but 347M
On Sat, Dec 11, 2021 at 6:46 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> Hi,
>
> on my laptop, /usr/bin/pipewire uses 56M RSS, 5M SHR,
> but/usr/bin/pipewire-pulse uses 347M RSS, 4M SHR.
> 56M is okeyish, but 347M seems a lot. I think firefox is going
> through pipewire-pulse, so that interface
Hi,
on my laptop, /usr/bin/pipewire uses 56M RSS, 5M SHR,
but/usr/bin/pipewire-pulse uses 347M RSS, 4M SHR.
56M is okeyish, but 347M seems a lot. I think firefox is going
through pipewire-pulse, so that interface might be getting more use
than native pipewire. But what are the expected values
11 matches
Mail list logo
