On Sun, Mar 28, 2021 at 10:36 PM Gleb Popov wrote:
> On Mon, Mar 29, 2021 at 4:37 AM David G Lawrence via freebsd-current <
> freebsd-current@freebsd.org> wrote:
>
> > > > On 27/03/21 06:04, David G Lawrence via freebsd-current wrote:
> > > >>> On Fri, Mar 26, 2021 at 1:01 PM Graham Perrin <
> >
> On Mon, Mar 29, 2021 at 4:37 AM David G Lawrence via freebsd-current <
> freebsd-current@freebsd.org> wrote:
>
> > > > On 27/03/21 06:04, David G Lawrence via freebsd-current wrote:
> > > >>> On Fri, Mar 26, 2021 at 1:01 PM Graham Perrin <
> > grahamper...@gmail.com>
> > > >>> wrote:
> > > >>>
On Mon, Mar 29, 2021 at 4:37 AM David G Lawrence via freebsd-current <
freebsd-current@freebsd.org> wrote:
> > > On 27/03/21 06:04, David G Lawrence via freebsd-current wrote:
> > >>> On Fri, Mar 26, 2021 at 1:01 PM Graham Perrin <
> grahamper...@gmail.com>
> > >>> wrote:
> > >>>
> > On
On Sunday, 28 March 2021 20:37:13 CDT David G Lawrence via freebsd-current
wrote:
> > > On 27/03/21 06:04, David G Lawrence via freebsd-current wrote:
> > >>> On Fri, Mar 26, 2021 at 1:01 PM Graham Perrin
> > >>> wrote:
> > >>>
> > On 26/03/2021 03:40, The Doctor via freebsd-current wrote:
> > On 27/03/21 06:04, David G Lawrence via freebsd-current wrote:
> >>> On Fri, Mar 26, 2021 at 1:01 PM Graham Perrin
> >>> wrote:
> >>>
> On 26/03/2021 03:40, The Doctor via freebsd-current wrote:
> > ??? if people are having issues with ports like ???
>
> If I'm not
This may be the problem fixed in
e9272225e6bed840b00eef1c817b188c172338ee ("vfs: fix vnlru marker
handling for filtered/unfiltered cases").
However, there is a long standing performance bug where if vnode limit
is hit, and there is nothing to reclaim, the code is just going to
sleep for one
Hi,
If anyone would like to review D29475, which adds required support
for BindConnectionToSession, please do so.
--> Needed to make callbacks to continue working after a TCP
reconnect occurs, due to a networking partition.
Until this patch is in a client, it is recommended to not run the
On 28/03/21 22:34, Guido Falsi via freebsd-current wrote:
On 27/03/21 06:04, David G Lawrence via freebsd-current wrote:
On Fri, Mar 26, 2021 at 1:01 PM Graham Perrin
wrote:
On 26/03/2021 03:40, The Doctor via freebsd-current wrote:
??? if people are having issues with ports like ???
If
On 27/03/21 06:04, David G Lawrence via freebsd-current wrote:
On Fri, Mar 26, 2021 at 1:01 PM Graham Perrin
wrote:
On 26/03/2021 03:40, The Doctor via freebsd-current wrote:
??? if people are having issues with ports like ???
If I'm not mistaken:
* 13.0-RC3 seems to be troublesome, as a
Am 28.03.21 um 17:44 schrieb Andriy Gapon:
On 28/03/2021 17:39, Stefan Esser wrote:
After a period of high load, my now idle system needs 4 to 10 seconds to
run any trivial command - even after 20 minutes of no load ...
I have run some Monte-Carlo simulations for a few hours, with initially
On Sat, Mar 27, 2021 at 5:07 AM dmilith . wrote:
> It may not only be Virtualbox, but also happens under Vmware VMs.
>
> I use Vmware Fusion 7 pro as my software build-host on top of my Mac
> Pro for years now, but I can't build much with 13.0 cause regular
> build processes (like sed, awk,
On 28/03/2021 17:39, Stefan Esser wrote:
> After a period of high load, my now idle system needs 4 to 10 seconds to
> run any trivial command - even after 20 minutes of no load ...
>
>
> I have run some Monte-Carlo simulations for a few hours, with initially 35
> processes running in parallel
>>I have trouble with recent 14.0-CURRENT 146 (e.x. main-6a762cfae,
>> main-3ead60236, main-25bfa4486).
>>It works well on recent 14.0-CURRENT until starting firefox.
>>If I start firefox (v87.0), system freeze but no core dumps.
>>If it booted old kernel 145 (e.x.
After a period of high load, my now idle system needs 4 to 10 seconds to
run any trivial command - even after 20 minutes of no load ...
I have run some Monte-Carlo simulations for a few hours, with initially 35
processes running in parallel for some 10 seconds each.
The load decreased over
On 28/03/2021 06:03, Masachika ISHIZUKA wrote:
I have trouble with recent 14.0-CURRENT 146 (e.x. main-6a762cfae,
main-3ead60236, main-25bfa4486).
It works well on recent 14.0-CURRENT until starting firefox.
If I start firefox (v87.0), system freeze but no core dumps.
If it booted
>>I have trouble with recent 14.0-CURRENT 146 (e.x. main-6a762cfae,
>> main-3ead60236, main-25bfa4486).
>>It works well on recent 14.0-CURRENT until starting firefox.
>>If I start firefox (v87.0), system freeze but no core dumps.
>>If it booted old kernel 145 (e.x.
On 3/27/21 11:54 AM, Santiago Martinez wrote:
Hi, i have the same output as @Nils B. If i run with steal =2 and dtrace
the micro stutter doesn't happen but as soon as i stop the dtrace script
it the stutters come back again.
Here is a patch which you can try. Not sure if it helps.
On 3/28/21 7:03 AM, Masachika ISHIZUKA wrote:
I have trouble with recent 14.0-CURRENT 146 (e.x. main-6a762cfae,
main-3ead60236, main-25bfa4486).
It works well on recent 14.0-CURRENT until starting firefox.
If I start firefox (v87.0), system freeze but no core dumps.
If it booted
18 matches
Mail list logo
