On Tue, 13 Apr 2021 17:18:42 -0400
Mark Johnston wrote:
> > P.S.
> > I have not been running any virtual machines.
> > I do use nvidia graphics driver.
>
In past I had report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238698
Now I switch to AMD and got only ~1Gb memory allocated by
On 14/04/2021 16:32, Mark Johnston wrote:
On Wed, Apr 14, 2021 at 02:21:44PM +0300, Andriy Gapon wrote:
On 14/04/2021 00:18, Mark Johnston wrote:
fbt::vm_page_unwire:entry
/args[0]->oflags & 0x4/
{
@unwire[stack()] = count();
}
Unrelated report, dtrace complains about this probe on
On Wed, Apr 14, 2021 at 02:21:44PM +0300, Andriy Gapon wrote:
> On 14/04/2021 00:18, Mark Johnston wrote:
> > fbt::vm_page_unwire:entry
> > /args[0]->oflags & 0x4/
> > {
> > @unwire[stack()] = count();
> > }
>
> Unrelated report, dtrace complains about this probe on my stable/13 system:
>
On 14/04/2021 00:18, Mark Johnston wrote:
fbt::vm_page_unwire:entry
/args[0]->oflags & 0x4/
{
@unwire[stack()] = count();
}
Unrelated report, dtrace complains about this probe on my stable/13 system:
failed to resolve translated type for args[0]
And I do not have any idea why...
On Tue, Apr 13, 2021 at 05:01:49PM +0300, Andriy Gapon wrote:
> On 07/04/2021 23:56, Mark Johnston wrote:
> > I don't know what might be causing it then. It could be a page leak.
> > The kernel allocates wired pages without adjusting the v_wire_count
> > counter in some cases, but the ones I know
On 07/04/2021 23:56, Mark Johnston wrote:
> I don't know what might be causing it then. It could be a page leak.
> The kernel allocates wired pages without adjusting the v_wire_count
> counter in some cases, but the ones I know about happen at boot and
> should not account for such a large
> -Original Message-
> From: owner-freebsd-curr...@freebsd.org curr...@freebsd.org> On Behalf Of Mark Johnston
> Sent: Wednesday, April 7, 2021 10:57 PM
> To: Andriy Gapon
> Cc: freebsd-stable List ; FreeBSD Current
>
> Subject: Re: stable/13, vm page counts d
On 8/04/2021 2:59 pm, Helge Oldach wrote:
> On Wed, Apr 07, 2021 at 10:42:57PM +0300, Andriy Gapon wrote:
>>
>> I regularly see that the top's memory line does not add up (and by a
>> lot).
>> That can be seen with vm.stats as well.
>>
>> For example:
>> $ sysctl
On 8/04/2021 6:56 am, Mark Johnston wrote:
> On Wed, Apr 07, 2021 at 11:22:41PM +0300, Andriy Gapon wrote:
>> On 07/04/2021 22:54, Mark Johnston wrote:
>>> On Wed, Apr 07, 2021 at 10:42:57PM +0300, Andriy Gapon wrote:
I regularly see that the top's memory line does not add up (and by a
On Wed, Apr 07, 2021 at 11:22:41PM +0300, Andriy Gapon wrote:
> On 07/04/2021 22:54, Mark Johnston wrote:
> > On Wed, Apr 07, 2021 at 10:42:57PM +0300, Andriy Gapon wrote:
> >>
> >> I regularly see that the top's memory line does not add up (and by a lot).
> >> That can be seen with vm.stats as
On 07/04/2021 22:54, Mark Johnston wrote:
> On Wed, Apr 07, 2021 at 10:42:57PM +0300, Andriy Gapon wrote:
>>
>> I regularly see that the top's memory line does not add up (and by a lot).
>> That can be seen with vm.stats as well.
>>
>> For example:
>> $ sysctl vm.stats | fgrep count
>>
On Wed, Apr 07, 2021 at 10:42:57PM +0300, Andriy Gapon wrote:
>
> I regularly see that the top's memory line does not add up (and by a lot).
> That can be seen with vm.stats as well.
>
> For example:
> $ sysctl vm.stats | fgrep count
> vm.stats.vm.v_cache_count: 0
>
12 matches
Mail list logo