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 same conditions. -- > https://lists.freebsd.org/pipermail/freebsd-stable/2011-December/064984.html > > And this describes quite exactly what I perceive. > Now, I would like to ask: what has been done about this issue? I see no reasons to use SHED_ULE for such single core systems and use SCHED_BSD. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
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 database file: # lz4 2058067.1 /dev/null And have this as throughput: poolalloc free read write read write cache - - - - - - ada1s47.08G 10.9G889 0 7.07M 42.3K PID USERNAME PRI NICE SIZERES STATETIMEWCPU COMMAND 51298 root870 16184K 7912K RUN 1:00 51.60% lz4 I start the piglet: $ while true; do :; done And, same effect: poolalloc free read write read write cache - - - - - - ada1s47.08G 10.9G 10 0 82.0K 0 PID USERNAME PRI NICE SIZERES STATETIMEWCPU COMMAND 1911 admin 980 7044K 2860K RUN 65:48 89.22% bash 51298 root520 16184K 7880K RUN 0:05 0.59% lz4 It does *not* happen with plain "cat" instead of "lz4". What may or may not have an influence on it: the respective filesystem is block=8k, and is 100% resident in l2arc. What is also interesting: I started trying this with "tar" (no effect, behaves properly), then with "tar --lz4". In the latter case "tar" starts "lz4" as a sub-process, so we have three processes in the play - and in that case the effect happens, but to lesser extent: about 75 I/Os per second. So, it seems quite clear that this has something to do with the logic inside the scheduler. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
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 demonstrates the problem and that anyone could run? Andriy, and maybe nobody anymore has such old system that is CPU-bound instead of IO-bound. I'd rather think about reproducing it on my IvyBridge. I know for sure that it is *not* specifically dependent on postgres. What I posted was the case when an endless-loop piglet starves a postgres VACUUM - and there we see a very pronounced effect of almost factor 100. When I first clearly discovered it (after a long time of belly-feeling that something behaves strange), it was postgres pg_dump (which does compression, i.e. CPU-bound) as the piglet starving an bacula-fd backup that would scan the filesystem. So, there is a general rule: we have one process that is a CPU-hog, and another process that does periodic I/O (but also *some* compute). and -important!- nothing else. If we understand the logic of the scheduler, that information should already suit for some logical verification *eg* - but I will see if I get it reprocuved on the IvyBridge machine and/or see if I get a testcase together. May take a while. P. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
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 and that anyone could run? -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
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 encouraging :) But I would say, running a job 100 times slower than expected is quite an amount of hate for my taste. A closer look shows the behaviour as follows (single CPU): A single CPU? That's becoming rare! Is that a VM? Old hardware? Something really specific? I don't plug in another CPU because there is no need to. Yes, its old hardware: CPU: Intel Pentium III (945.02-MHz 686-class CPU) ACPI APIC Table: If I had bought new hardware, this one would now rot in Africa, and I would have new hardware idling along that is spectre/meltdown affected nevertheless. Lets run an I/O-active task, e.g, postgres VACUUM that would And you're running a multi-process database server on it no less. That > is going to hurt, I'm running a lot more than only that on it. But it's all private use, idling most of the time. no matter how well the scheduler works. Maybe. But this post is not about my personal expectations on over-all performance - it is about a specific behaviour that is not how a scheduler is expected to behave - no matter if we're on a PDP-11 or on a KabyLake. Now, as usual, the "root-cause" questions arise: What exactly does this "quantum"? Is this solution a workaround, i.e. actually something else is wrong, and has it tradeoff in other situations? Or otherwise, why is such a default value chosen, which appears to be ill-deceived? The docs for the quantum parameter are a bit unsatisfying - they say its the max num of ticks a process gets - and what happens when they're exhausted? If by default the endless loop is actually allowed to continue running for 94k ticks (or 94ms, more likely) uninterrupted, then that explains the perceived behaviour - buts thats certainly not what a scheduler should do when other procs are ready to run. I can answer this from the operating systems course I followed recently. This does not apply to FreeBSD specifically, it is general job scheduling theory. I still need to read up on SCHED_ULE to see how the details were implemented there. Or are you using the older SCHED_4BSD? I'm using the default scheduler, which is ULE. I would not go non-default without reason. (But it seems, a reason is just appering now.) Now, that would cause a much worse situation in your example case. The endless loop would keep running once it gets the CPU and would never release it. No other process would ever get a turn again. You wouldn't even be able to get into such a system in that state using remote ssh. That is why the scheduler has this "quantum", which limits the maximum time the CPU will be assigned to a specific job. Once the quantum has expired (with the job unfinished), the scheduler removes the job from the CPU, puts it back on the ready queue and assigns the next job from that queue to the CPU. That's why you seem to get better performance with a smaller value for the quantum; the endless loop gets forcibly interrupted more often. Good description. Only my (old-fashioned) understanding was that this is the purpose of the HZ value: to give control back to the kernel, so that a new decision can be made. So, I would not have been surpized to see 200 I/Os for postgres (kern.hz=200), but what I see is 9 I/Os (which indeed figures to a "quantum" of 94ms). But then, we were able to do all this nicely on single-CPU machines for almost four decades. It does not make sense to me if now we state that we cannot do it anymore because single-CPU is uncommon today. (Yes indeed, we also cannot fly to the moon anymore, because today nobody seems to recall how that stuff was built. *headbangwall*) This changing of the active job however, involves a context switch for the CPU. Memory, registers, file handles, etc. that were required by the previous job needs to be put aside and replaced by any such resources related to the new job to be run. That uses up time and does nothing to progress the jobs that are waiting for the CPU. Hence, you don't want the quantum to be too small either, or you'll end up spending significant time switching contexts. Yepp. My understanding was that I can influence this behaviour via the HZ value, so to tradeoff responsiveness against performance. Obviousely that was wrong. From Your writing, it seems the "quantum" is indeed the correct place to tune this. (But I will still have to ponder a while about the knob mentioned by Stefan, concerning preemption, which seems to magically resolve the issue.) 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 gi
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, if you're not already on SCHED_4BSD. [...] A small, disgruntled community of FreeBSD users who have never seen proof that SCHED_ULE is better than SCHED_4BSD in any environment continue to regularly recompile with SCHED_4BSD. I dread the day when that becomes impossible, but at least it isn't here yet. -- George Yes *laugh*, I found a very lengthy and mind-boggling discussion from back in 2011. And I found that You made this statement somewhere there: // 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 same conditions. -- https://lists.freebsd.org/pipermail/freebsd-stable/2011-December/064984.html And this describes quite exactly what I perceive. Now, I would like to ask: what has been done about this issue? P. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
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! Only it is actually the other way round: it is not set to 0. My settings (as default) are: kern.sched.steal_thresh: 2 kern.sched.steal_idle: 1 kern.sched.balance_interval: 127 kern.sched.balance: 1 kern.sched.affinity: 1 kern.sched.idlespinthresh: 157 kern.sched.idlespins: 1 kern.sched.static_boost: 152 kern.sched.preempt_thresh: 80 kern.sched.interact: 30 kern.sched.slice: 12 kern.sched.quantum: 94488 kern.sched.name: ULE kern.sched.preemption: 1 kern.sched.cpusetsize: 4 But then, if I change kern.sched.preempt_thresh to 1 *OR* 0, things behave properly! Precisely, changing from 8 down to 7 changes things completely: >poolalloc free read write read write >cache - - - - - - > ada1s47.08G 10.9G927 0 7.32M 0 > PID USERNAME PRI NICE SIZERES STATETIMEWCPU COMMAND > 1900 pgsql 820 618M 17532K RUN 0:53 34.90% postgres > 1911 admin 810 7044K 2824K RUN 6:07 28.34% bash (Notice the PRI values which also look differnt now.) rgds, P. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
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 [mailto:veronica.ba...@showezdeligates.com] Sent: 29 March 2018 12:59 To: 'freebsd-stable@freebsd.org' Subject: Delegates Email list of Atlanta Apartment Association 2018 Hi, Would you be interested in Attendees Email List Of Atlanta Apartment Association 2018.? Attendees: . Decision Makers . Apartment owners . Managers . Suppliers, and Professionals List includes: E-mails, contact number and other fields on an excel sheet. Would you like to see counts and pricing details available.? Looking forward for your email. Regards, Veronica Baker| B.D.Exe If you do not wish to receive future emails from us, please reply as "Exclude Me" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
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 already on SCHED_4BSD. > [...] A small, disgruntled community of FreeBSD users who have never seen proof that SCHED_ULE is better than SCHED_4BSD in any environment continue to regularly recompile with SCHED_4BSD. I dread the day when that becomes impossible, but at least it isn't here yet. -- George signature.asc Description: OpenPGP digital signature
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 the scheduler, and decided it hates me. > > If it hated you, it would behave much worse. > >> A closer look shows the behaviour as follows (single CPU): > > A single CPU? That's becoming rare! Is that a VM? Old hardware? Something > really specific? > >> Lets run an I/O-active task, e.g, postgres VACUUM that would > > And you're running a multi-process database server on it no less. That is > going to hurt, no matter how well the scheduler works. > >> continuousely read from big files (while doing compute as well [1]): >>> poolalloc free read write read write >>> cache - - - - - - >>> ada1s47.08G 10.9G 1.58K 0 12.9M 0 >> >> Now start an endless loop: >> # while true; do :; done >> >> And the effect is: >>> poolalloc free read write read write >>> cache - - - - - - >>> ada1s47.08G 10.9G 9 0 76.8K 0 >> >> The VACUUM gets almost stuck! This figures with WCPU in "top": >> >>> PID USERNAME PRI NICE SIZERES STATETIMEWCPU COMMAND >>> 85583 root990 7044K 1944K RUN 1:06 92.21% bash >>> 53005 pgsql 520 620M 91856K RUN 5:47 0.50% postgres >> >> Hacking on kern.sched.quantum makes it quite a bit better: >> # sysctl kern.sched.quantum=1 >> kern.sched.quantum: 94488 -> 7874 >> >>> poolalloc free read write read write >>> cache - - - - - - >>> ada1s47.08G 10.9G395 0 3.12M 0 >> >>> PID USERNAME PRI NICE SIZERES STATETIMEWCPU COMMAND >>> 85583 root940 7044K 1944K RUN 4:13 70.80% bash >>> 53005 pgsql 520 276M 91856K RUN 5:52 11.83% postgres >> >> >> Now, as usual, the "root-cause" questions arise: What exactly does >> this "quantum"? Is this solution a workaround, i.e. actually something >> else is wrong, and has it tradeoff in other situations? Or otherwise, >> why is such a default value chosen, which appears to be ill-deceived? >> >> The docs for the quantum parameter are a bit unsatisfying - they say >> its the max num of ticks a process gets - and what happens when >> they're exhausted? If by default the endless loop is actually allowed >> to continue running for 94k ticks (or 94ms, more likely) uninterrupted, >> then that explains the perceived behaviour - buts thats certainly not >> what a scheduler should do when other procs are ready to run. > > I can answer this from the operating systems course I followed recently. This > does not apply to FreeBSD specifically, it is general job scheduling theory. > I still need to read up on SCHED_ULE to see how the details were implemented > there. Or are you using the older SCHED_4BSD? > Anyway... > > Jobs that are ready to run are collected on a ready queue. Since you have a > single CPU, there can only be a single job active on the CPU. When that job > is finished, the scheduler takes the next job in the ready queue and assigns > it to the CPU, etc. 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 to see whether it makes a difference. The value 1 is unreasonably low, but it has the most visible effect in that any higher priority process can steal the CPU from any lower priority one (high priority corresponds to low PRI values as displayed by ps -l or top). Reasonable values might be in the range of 80 to 224 depending on the system usage scenario (that's what I found to have been suggested in the mail-lists). Higher values result in less preemption. Regards, STefan ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
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 you, it would behave much worse. > A closer look shows the behaviour as follows (single CPU): A single CPU? That's becoming rare! Is that a VM? Old hardware? Something really specific? > Lets run an I/O-active task, e.g, postgres VACUUM that would And you're running a multi-process database server on it no less. That is going to hurt, no matter how well the scheduler works. > continuousely read from big files (while doing compute as well [1]): > >poolalloc free read write read write > >cache - - - - - - > > ada1s47.08G 10.9G 1.58K 0 12.9M 0 > > Now start an endless loop: > # while true; do :; done > > And the effect is: > >poolalloc free read write read write > >cache - - - - - - > > ada1s47.08G 10.9G 9 0 76.8K 0 > > The VACUUM gets almost stuck! This figures with WCPU in "top": > > > PID USERNAME PRI NICE SIZERES STATETIMEWCPU COMMAND > >85583 root990 7044K 1944K RUN 1:06 92.21% bash > >53005 pgsql 520 620M 91856K RUN 5:47 0.50% postgres > > Hacking on kern.sched.quantum makes it quite a bit better: > # sysctl kern.sched.quantum=1 > kern.sched.quantum: 94488 -> 7874 > > >poolalloc free read write read write > >cache - - - - - - > > ada1s47.08G 10.9G395 0 3.12M 0 > > > PID USERNAME PRI NICE SIZERES STATETIMEWCPU COMMAND > >85583 root940 7044K 1944K RUN 4:13 70.80% bash > >53005 pgsql 520 276M 91856K RUN 5:52 11.83% postgres > > > Now, as usual, the "root-cause" questions arise: What exactly does > this "quantum"? Is this solution a workaround, i.e. actually something > else is wrong, and has it tradeoff in other situations? Or otherwise, > why is such a default value chosen, which appears to be ill-deceived? > > The docs for the quantum parameter are a bit unsatisfying - they say > its the max num of ticks a process gets - and what happens when > they're exhausted? If by default the endless loop is actually allowed > to continue running for 94k ticks (or 94ms, more likely) uninterrupted, > then that explains the perceived behaviour - buts thats certainly not > what a scheduler should do when other procs are ready to run. I can answer this from the operating systems course I followed recently. This does not apply to FreeBSD specifically, it is general job scheduling theory. I still need to read up on SCHED_ULE to see how the details were implemented there. Or are you using the older SCHED_4BSD? Anyway... Jobs that are ready to run are collected on a ready queue. Since you have a single CPU, there can only be a single job active on the CPU. When that job is finished, the scheduler takes the next job in the ready queue and assigns it to the CPU, etc. Now, that would cause a much worse situation in your example case. The endless loop would keep running once it gets the CPU and would never release it. No other process would ever get a turn again. You wouldn't even be able to get into such a system in that state using remote ssh. That is why the scheduler has this "quantum", which limits the maximum time the CPU will be assigned to a specific job. Once the quantum has expired (with the job unfinished), the scheduler removes the job from the CPU, puts it back on the ready queue and assigns the next job from that queue to the CPU. That's why you seem to get better performance with a smaller value for the quantum; the endless loop gets forcibly interrupted more often. This changing of the active job however, involves a context switch for the CPU. Memory, registers, file handles, etc. that were required by the previous job needs to be put aside and replaced by any such resources related to the new job to be run. That uses up time and does nothing to progress the jobs that are waiting for the CPU. Hence, you don't want the quantum to be too small either, or you'll end up spending significant time switching contexts. That gets worse when the job involves system calls, which are handled by the kernel, which is also a process that needs to be switched (and Meltdown made that worse, because more rigorous clean-up is necessary to prevent peeks into sections of memory that were owned by the kernel process previously). The "correct" value for the quantum depends on your type of workload. PostgreSQL's auto-vacuum is a typical background process that will probably (I didn't verify) request to be run at a lower priority, giving other, more important, jobs more chance to get picked from the ready qu
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 ? And why logicalused is 34.2G ? On one hand, 34.2G exactlyfits to the 1.86x compresstaio, but still I don't get it. dataset is on raidz, 3 spans across 5 disk vdevs, with total of 15 disks if it matters: A sparse file, possibly? The ZFS numbers refer to blocks. "Skipping" zeroes at the VFS layer is not taken into account as fas as I know. Seriously, how should it? If I'm not mistaken, ZFS will never get to see these empty blocks. Looks so, thanks. Although it's a mysql tablespace file. But yeah, in hex viewer looks like it's filled with zeroes in many places. Eugene. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
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 hand, 34.2G exactlyfits to the 1.86x compresstaio, but still I don't get > it. dataset is on raidz, 3 spans across 5 disk vdevs, with total of 15 disks > if it matters: A sparse file, possibly? The ZFS numbers refer to blocks. "Skipping" zeroes at the VFS layer is not taken into account as fas as I know. Seriously, how should it? If I'm not mistaken, ZFS will never get to see these empty blocks. Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
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. dataset is on raidz, 3 spans across 5 disk vdevs, with total of 15 disks if it matters: # du -h 18G. # ls -lh total 19316318 -rw-r- 1 root wheel 232G 4 апр. 11:29 mp_userCoordsHistory.ibd # zfs get all data/test NAME PROPERTY VALUE SOURCE data/test type filesystem - data/test creation ср апр. 4 10:31 2018 - data/test used 18,4G - data/test available 9,95T - data/test referenced18,4G - data/test compressratio 1.86x - data/test mounted yes - data/test quota none default data/test reservation none default data/test recordsize128K default data/test mountpoint/data/test default data/test sharenfs off default data/test checksum on default data/test compression lz4 local data/test atime on default data/test devices on default data/test exec on default data/test setuidon default data/test readonly off default data/test jailedoff default data/test snapdir hidden default data/test aclmode discard default data/test aclinheritrestricted default data/test canmount on default data/test xattr off temporary data/test copies1 default data/test version 5 - data/test utf8only off - data/test normalization none- data/test casesensitivity sensitive - data/test vscan off default data/test nbmandoff default data/test sharesmb off default data/test refquota none default data/test refreservationnone default data/test primarycache all default data/test secondarycacheall default data/test usedbysnapshots 0 - data/test usedbydataset 18,4G - data/test usedbychildren0 - data/test usedbyrefreservation 0 - data/test logbias latency default data/test dedup on inherited from data data/test mlslabel - data/test sync standard default data/test refcompressratio 1.86x - data/test written 18,4G - data/test logicalused 34,2G - data/test logicalreferenced 34,2G - data/test volmode default default data/test filesystem_limit none default data/test snapshot_limitnone default data/test filesystem_count none default data/test snapshot_countnone default data/test redundant_metadataall default # zpool status pool: data state: ONLINE scan: scrub repaired 0 in 28h24m with 0 errors on Thu Feb 15 13:26:36 2018 config: NAMESTATE READ WRITE CKSUM dataONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 da4 ONLINE 0 0 0 da5 ONLINE 0 0 0 da6 ONLINE 0 0 0 raidz1-1 ONLINE 0 0 0 da7 ONLINE 0 0 0 da8 ONLINE 0 0 0 da9 ONLINE 0 0 0 da10ONLINE 0 0 0 da11ONLINE 0 0 0 raidz1-2 ONLINE 0 0 0 da12ONLINE 0 0 0 da13ONLINE 0 0 0 da14ONLINE 0 0 0 da15ONLINE 0 0 0 da16ONLINE 0 0 0 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[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&action=edit Kernel config file Attached kernel config. My kernel is close to generic, extras are: > options IPFIREWALL > options IPDIVERT > options DUMMYNET then added these for debug, but the problem occurred without them: > options KDB_UNATTENDED > options DDB # Support DDB. > options GDB # Support remote GDB. > options INVARIANTS # Enable calls of extra sanity > checking > options INVARIANT_SUPPORT # Extra sanity checks of internal > structures, required by INVARIANTS > options WITNESS # Enable checks to detect deadlocks > and cycles > options WITNESS_SKIPSPIN# Don't run witness on spinlocks for > speed You've probably got these from loader.conf, but I also have these: mkn@shrewd$ kldstat Id Refs AddressSize Name 1 35 0x8020 17dbb70 kernel 21 0x819dc000 215a8geom_eli.ko 32 0x819fe000 352d0crypto.ko 41 0x81a34000 23fb0geom_mirror.ko 51 0x81a58000 157c0aio.ko 61 0x81a6e000 4a70 coretemp.ko 71 0x81a73000 b188 sem.ko 81 0x81a7f000 26e0 cc_cubic.ko 91 0x81c11000 56c6 fdescfs.ko 101 0x81c17000 8df4 uftdi.ko 111 0x81c2 54c4 ucom.ko 121 0x81c26000 3d12clinux.ko 132 0x81c64000 683b linux_common.ko 141 0x81c6b000 37ae9linux64.ko -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"