Re: kern.sched.quantum: Creepy, sadistic scheduler

04.04.2018 21:16, Peter wrote: > // With nCPU compute-bound processes running, with SCHED_ULE, any other > // process that is interactive (which to me means frequently waiting for > // I/O) gets ABYSMAL performance -- over an order of magnitude worse > // than it gets with SCHED_4BSD under the

Re: kern.sched.quantum: Creepy, sadistic scheduler

Andriy Gapon wrote: Not everyone has a postgres server and a suitable database. Could you please devise a test scenario that demonstrates the problem and that anyone could run? Alright, simple things first: I can reproduce the effect without postgres, with regular commands. I run this on my

Re: kern.sched.quantum: Creepy, sadistic scheduler

Andriy Gapon wrote: On 04/04/2018 03:52, Peter wrote: Lets run an I/O-active task, e.g, postgres VACUUM that would continuousely read from big files (while doing compute as well [1]): Not everyone has a postgres server and a suitable database. Could you please devise a test scenario that

Re: kern.sched.quantum: Creepy, sadistic scheduler

On 04/04/2018 03:52, Peter wrote: > Lets run an I/O-active task, e.g, postgres VACUUM that would > continuousely read from big files (while doing compute as well [1]): Not everyone has a postgres server and a suitable database. Could you please devise a test scenario that demonstrates the problem

Re: kern.sched.quantum: Creepy, sadistic scheduler

On 04/04/18 10:34, Peter wrote: > [...] It does not make sense to me if now we state that > we cannot do it anymore because single-CPU is uncommon today. > [...] +1.-- George signature.asc Description: OpenPGP digital signature

Re: kern.sched.quantum: Creepy, sadistic scheduler

Hi Alban! Alban Hertroys wrote: Occasionally I noticed that the system would not quickly process the tasks i need done, but instead prefer other, longrunning tasks. I figured it must be related to the scheduler, and decided it hates me. If it hated you, it would behave much worse. Thats

Re: kern.sched.quantum: Creepy, sadistic scheduler

George Mitchell wrote: On 04/04/18 06:39, Alban Hertroys wrote: [...] That said, SCHED_ULE (the default scheduler for quite a while now) was designed with multi-CPU configurations in mind and there are claims that SCHED_4BSD works better for single-CPU configurations. You may give that a try,

Re: Try setting kern.sched.preempt_thresh != 0

Stefan Esser wrote: I'm guessing that the problem is caused by kern.sched.preempt_thresh=0, which prevents preemption of low priority processes by interactive or I/O bound processes. For a quick test try: # sysctl kern.sched.preempt_thresh=1 Hi Stefan, thank You, thats an interesting knob!

RE: Delegates Email list of Atlanta Apartment Association 2018

Hi, I hope you're doing well. I was wondering if you had a chance to review my previous email that I sent to you. Kindly let me know your interest so that i can get back to you with counts and pricing available. Best Regards, Veronica Baker From: Veronica Baker

Re: kern.sched.quantum: Creepy, sadistic scheduler

On 04/04/18 06:39, Alban Hertroys wrote: > [...] > That said, SCHED_ULE (the default scheduler for quite a while now) was > designed with multi-CPU configurations in mind and there are claims that > SCHED_4BSD works better for single-CPU configurations. You may give that a > try, if you're not

Try setting kern.sched.preempt_thresh != 0 (was: Re: kern.sched.quantum: Creepy, sadistic scheduler)

Am 04.04.18 um 12:39 schrieb Alban Hertroys: > >> On 4 Apr 2018, at 2:52, Peter wrote: >> >> Occasionally I noticed that the system would not quickly process the >> tasks i need done, but instead prefer other, longrunning tasks. I >> figured it must be related to

Re: kern.sched.quantum: Creepy, sadistic scheduler

> On 4 Apr 2018, at 2:52, Peter wrote: > > Occasionally I noticed that the system would not quickly process the > tasks i need done, but instead prefer other, longrunning tasks. I > figured it must be related to the scheduler, and decided it hates me. If it hated

Re: another question about zfs compression numbers

Hi, On 04.04.2018 12:35, Patrick M. Hausen wrote: Hi all, Am 04.04.2018 um 09:21 schrieb Eugene M. Zheganin : I'm just trying to understand these numbers: file size is 232G, it's actual size on the lz4-compressed dataset is 18G, so then why is the compressratio only 1.86x

Re: another question about zfs compression numbers

Hi all, > Am 04.04.2018 um 09:21 schrieb Eugene M. Zheganin : > I'm just trying to understand these numbers: > > file size is 232G, it's actual size on the lz4-compressed dataset is 18G, so > then why is the compressratio only 1.86x ? And why logicalused is 34.2G ? On > one

another question about zfs compression numbers

Hello, I'm just trying to understand these numbers: file size is 232G, it's actual size on the lz4-compressed dataset is 18G, so then why is the compressratio only 1.86x ? And why logicalused is 34.2G ? On one hand, 34.2G exactlyfits to the 1.86x compresstaio, but still I don't get it.

[Bug 227213] FreeBSD 10.4 kernel deadlocks on sysctlmemlock

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227213 --- Comment #15 from Mark Knight --- Created attachment 192199 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192199=edit Kernel config file Attached kernel config. My kernel is close to generic, extras are:

[Bug 227213] FreeBSD 10.4 kernel deadlocks on sysctlmemlock

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227213 --- Comment #14 from Eugene Grosbein --- (In reply to Mark Knight from comment #13) Do you use GENERIC kernel? If not, please attach your kernel config file. -- You are receiving this mail because: You are the