Re: official pkg repo with WITHOUT_X11=true
On 29 May 2014, at 23:06, Andreas Nilsson wrote: > Having a "parent" set would be nice, yes. I maintain two repos for several > FreeBSD-versions. Being able to pull some of the deps from packages instead > of blindingly building would be nice. Yes, for a lot of cases you only want to build a small handful of packages with different options, so it would be nice if you could find out exactly what the options were for the upstream build and only build the packages yourself if you've specified different options or depend on a package with different options. The problem is the notion of dependency here. In some cases, linking against a shared library built with different options won't change your program's code, it will just make more things work. In other cases, you'll have different things exposed in headers and even build-only dependencies will impact the output. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cpuid_t typedef? (was Re: Processor cores not properly detected/activated?)
On Thursday, May 29, 2014 5:46:05 pm Adrian Chadd wrote: > On 29 May 2014 14:29, John Baldwin wrote: > > On Thursday, May 29, 2014 5:09:05 pm Adrian Chadd wrote: > >> On 29 May 2014 13:18, John Baldwin wrote: > >> > >> >> anyway. Besides all of this - I'm thinking of just introducing: > >> >> > >> >> typedef uint32_t cpuid_t; > >> >> > >> >> .. then once we've converted all the users, we can make NOCPU > >> >> something other than 255 (which is the other limiting factor here..) > >> >> > >> >> Any objections? > >> > > >> > This one is a bit harder as you'll have to do shims for kinfo_proc, but > >> > I think this is fine. You could also just use u_int, but a new foo_t > >> > isn't that bad I guess. > >> > >> I don't think I'd modify any userland-facing ABI/KBI's just yet. I'm > >> just worried that 11.0-REL will come out before we have made a decent > >> inroads into this and we _can't_ support > 254 CPUs. > > > > Eh, that's one of the biggies to do actually. Kind of pointless to > > update td_oncpu/lastcpu and not fix kinfo_proc at the same time. You'll > > just have to add new int fields and populate the old ones with sane values > > for CPUs < 255. > > Ugh. Ok. I was too deep in the trenches of device drivers and other > ancillary things doing bad things to char/short with cpu ids when > walking things. I totally missed kinfo_proc. > > I'll go think about it a bit more. It shouldn't be too hard to to handle kinfo_proc. pf is another case. It might be nice to have a way to auto-compute the right number of bits to reserve based on MAXCPU. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH] Cleanups for hpt27xx(4)
These patches switch hpt27xx(4) from timeout() to callout() and fix it to use its existing locks in place of Giant for CAM along with some other cleanups. If anyone has any hardware I suspect the ioctl handling is buggy, but I'm more hesitant to touch that unless someone has multiple adapters in a single box. Please be sure to test with INVARIANTS and INVARIANT_SUPPORT enabled. http://people.FreeBSD.org/~jhb/patches/hpt27xx_locking.patch -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cpuid_t typedef? (was Re: Processor cores not properly detected/activated?)
On 30 May 2014 07:57, John Baldwin wrote: >> Ugh. Ok. I was too deep in the trenches of device drivers and other >> ancillary things doing bad things to char/short with cpu ids when >> walking things. I totally missed kinfo_proc. >> >> I'll go think about it a bit more. > > It shouldn't be too hard to to handle kinfo_proc. pf is another case. It > might be nice to have a way to auto-compute the right number of bits to > reserve based on MAXCPU. *nod* ok. Let me go and start sprinkling things around. -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Change top's notion of idle processes / threads
John Baldwin wrote: > Yes, I actually started by sorting on the raw delta and ended up going back > and fixing > pctcpu instead. However, there is a problem in this case which is that you > still want to fall back to ki_pctcpu if you don't have a valid previous delta > to compare against. It's a lot simpler to just fixup ki_pctcpu and not have > to go > change the sorting code explicitly. :( I actually started out having a > function that > returned a double for the pctcpu, but that would mean recalculating the raw > pctcpu > many, many times during the sort. Just updating ki_pctcpu once per each > process/thread > per fetch scales a bit better. I could perhaps use an array to cache raw > percentages > as doubles. Sorry for the delay in getting back to you. Thanks for the explanation - it makes sense. (I mean that I understand what you are saying - not that I'm somehow misguidingly attempting to give my approval!) I can see how improving the granularity of pctcpu would be a much cleaner solution - I just didn't know which solution was easier (and after finally looking at the source, I still didn't know :-) ) > Ok, try people.freebsd.org/~jhb/patches/top_pctcpu2.patch Brilliant. I wasn't able to get contradictory results this time - however much I tried! I have a few server processes that are constantly active (receiving many requests per second) but use a well written piece of code that handles them efficiently. With the stock 10-stable, and with the previous patch, they always registered as 0.00% cpu (and consequently were not shown at all in idle-only mode on 10-stable) (I'm not doubting the general stats - I reconfigured one of them earier today, and in 7 hours it's clocked up 2.2 seconds) With the latest patch, they now report as 0:01% which not only corrects the sort order, but makes more sense than 0.00% for a non-idle process, even if the value before rounded is closer to 0.00 than 0.01 Other processes which are generally in tick-over, but also idle much of the time now pop in and out of view as expected, and sorted as expected. not sure what you've done I'm guessing without looking at the patch code (lazy persons approach) that you have either improved the accuracy of pctcpu, or you now round any non-idle cpu usage below 0.00 up to 0.01 Whatever It works. The old top was mainly handy for watching heavy usage processes (don't get me wrong, it's invaluable for that). The new top is now also producing results similar to what I'd previously had to manually extrapolate from a series of repeated targetted 'ps' commands. I'll let you know if I notice anything weird, or if I manage to break anything :-) but I'm confident that this won't happen. A BIG thumbs up for this... Push into current, then MFC now! :-) Cheers, Jamie ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Change top's notion of idle processes / threads
On May 28, 2014, at 9:54, John Baldwin wrote: > Yes, I actually started by sorting on the raw delta and ended up going back > and fixing > pctcpu instead. However, there is a problem in this case which is that you > still want to fall back to ki_pctcpu if you don't have a valid previous delta > to compare against. It's a lot simpler to just fixup ki_pctcpu and not have > to go > change the sorting code explicitly. :( I actually started out having a > function that > returned a double for the pctcpu, but that would mean recalculating the raw > pctcpu > many, many times during the sort. Just updating ki_pctcpu once per each > process/thread > per fetch scales a bit better. I could perhaps use an array to cache raw > percentages > as doubles. > > Ok, try people.freebsd.org/~jhb/patches/top_pctcpu2.patch > Hey, all the 0.00% processes on my server now show up in top with measurable usage. Nice. (They're all between 0.3% and 0.9%) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipmi patch for review
On Thu, Sep 19, 2013 at 03:04:46PM -0400, John Baldwin wrote: | On Tuesday, September 17, 2013 6:21:10 am Gleb Smirnoff wrote: | > Hi! | > | > When system is writing a kernel core dump, it issues watchdog | > pat wdog_kern_pat(WD_LASTVAL). If ipmi is in action, it registers | > ipmi_wd_event() as event for watchdog. Thus ipmi_wd_event() is | > called in dumping context. | > | > The problem is that ipmi_wd_event() calls into ipmi_set_watchdog(), | > that calls into ipmi_alloc_request(), which uses M_WAITOK and | > thus sleeps. This is a smaller problem, since can be converted to | > M_NOWAIT. But ipmi_set_watchdog() then calls into | > ipmi_submit_driver_request(), which calls msleep() any time. | > | > The attached patch allows me to successfully write cores in | > presence of IPMI. | | Of course, the watchdog might go off during your dump. :) | | The real fix is more complicated, which is that we should not use | a worker thread for at least SMIC and KCS. I haven't looked at this patch but I have local code that switches KCS into polling direct mode when the kernel goes into panic mode. I use this to write Linux compatible back traces into the system event logs. This could allow the watchdogd to continue to work. This should be easily extended to SMIC mode. SMBUS would be harder but at a prior company I made the SMBIO driver work in polled mode. If someone wants to look at this I can post the changes for KCS and the kernel backtrace to the system event log. We find this useful when looking at customer machines. IPMI gets upset if things get intermixed/interrupted so there needs to be serialization and cancellation if being interrupted. Thanks, Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on armv6/arm
TB --- 2014-05-30 14:40:36 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-05-30 14:40:36 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-30 14:40:36 - starting HEAD tinderbox run for armv6/arm TB --- 2014-05-30 14:40:36 - cleaning the object tree TB --- 2014-05-30 14:40:36 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-30 14:40:41 - At svn revision 266887 TB --- 2014-05-30 14:40:42 - building world TB --- 2014-05-30 14:40:42 - CROSS_BUILD_TESTING=YES TB --- 2014-05-30 14:40:42 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-30 14:40:42 - MAKESYSPATH=/src/share/mk TB --- 2014-05-30 14:40:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-30 14:40:42 - SRCCONF=/dev/null TB --- 2014-05-30 14:40:42 - TARGET=arm TB --- 2014-05-30 14:40:42 - TARGET_ARCH=armv6 TB --- 2014-05-30 14:40:42 - TZ=UTC TB --- 2014-05-30 14:40:42 - __MAKE_CONF=/dev/null TB --- 2014-05-30 14:40:42 - cd /src TB --- 2014-05-30 14:40:42 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Fri May 30 14:40:49 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri May 30 17:58:09 UTC 2014 TB --- 2014-05-30 17:58:09 - generating LINT kernel config TB --- 2014-05-30 17:58:09 - cd /src/sys/arm/conf TB --- 2014-05-30 17:58:09 - /usr/bin/make -B LINT TB --- 2014-05-30 17:58:09 - cd /src/sys/arm/conf TB --- 2014-05-30 17:58:09 - /obj/arm.armv6/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-05-30 17:58:09 - skipping LINT kernel TB --- 2014-05-30 17:58:09 - cd /src/sys/arm/conf TB --- 2014-05-30 17:58:09 - /obj/arm.armv6/src/tmp/legacy/usr/sbin/config -m AC100 TB --- 2014-05-30 17:58:09 - building AC100 kernel TB --- 2014-05-30 17:58:09 - CROSS_BUILD_TESTING=YES TB --- 2014-05-30 17:58:09 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-30 17:58:09 - MAKESYSPATH=/src/share/mk TB --- 2014-05-30 17:58:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-30 17:58:09 - SRCCONF=/dev/null TB --- 2014-05-30 17:58:09 - TARGET=arm TB --- 2014-05-30 17:58:09 - TARGET_ARCH=armv6 TB --- 2014-05-30 17:58:09 - TZ=UTC TB --- 2014-05-30 17:58:09 - __MAKE_CONF=/dev/null TB --- 2014-05-30 17:58:09 - cd /src TB --- 2014-05-30 17:58:09 - /usr/bin/make -B buildkernel KERNCONF=AC100 >>> Kernel build for AC100 started on Fri May 30 17:58:09 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AC100 completed on Fri May 30 18:01:13 UTC 2014 TB --- 2014-05-30 18:01:13 - cd /src/sys/arm/conf TB --- 2014-05-30 18:01:13 - /obj/arm.armv6/src/tmp/legacy/usr/sbin/config -m ARMADAXP TB --- 2014-05-30 18:01:13 - building ARMADAXP kernel TB --- 2014-05-30 18:01:13 - CROSS_BUILD_TESTING=YES TB --- 2014-05-30 18:01:13 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-30 18:01:13 - MAKESYSPATH=/src/share/mk TB --- 2014-05-30 18:01:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-30 18:01:13 - SRCCONF=/dev/null TB --- 2014-05-30 18:01:13 - TARGET=arm TB --- 2014-05-30 18:01:13 - TARGET_ARCH=armv6 TB --- 2014-05-30 18:01:13 - TZ=UTC TB --- 2014-05-30 18:01:13 - __MAKE_CONF=/dev/null TB --- 2014-05-30 18:01:13 - cd /src TB --- 2014-05-30 18:01:13 - /usr/bin/make -B buildkernel KERNCONF=ARMADAXP >>> Kernel build for ARMADAXP started on Fri May 30 18:01:13 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ARMADAXP completed on Fri May 30 18:05:16 UTC 2014 TB --- 2014-05-30 18:05:16 - cd /src/sys/arm/conf TB --- 2014-05-30 18:05:16 - /obj/arm.armv6/src/tmp/legacy/usr/sbin/config -m ARNDALE TB --- 2014-05-30 18:05:16 - building ARNDALE kernel TB --- 2014-05-30 18:05:16 - CROSS_BUILD_TESTING=YES TB --- 2014-05-30 18:05:16 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-30 18:05:16 - MAKESYSPATH=/src/share/mk TB --- 2014-05-30 18:05:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-30 18:05:16 - SRCCONF=/dev/null TB --- 2014-05-30 18:05:16 - TARGET=arm TB --- 2014-05-30 18:05:16 - TARGET_ARCH=armv6 TB --- 2014-05-30 18:05:16 - TZ=UTC TB --- 2014-05-30 18:05:16 - __MAKE_CONF=/dev/null TB --- 2014-05-30 18:05:16 - cd /src TB --- 2014-05-30 18:05:16 - /usr/bin/make -B buildkernel KERNCONF=ARNDALE >>> Kernel build for ARNDALE started on Fri Ma
Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable
On Fri, May 23, 2014 at 08:35:25PM -0400, Shawn Webb wrote: > On May 23, 2014 07:53 PM +, Wojciech A. Koszek wrote: > > On Wed, May 14, 2014 at 09:58:52AM -0400, Shawn Webb wrote: > > > Hey All, > > > > > > [NOTE: crossposting between freebsd-current@, freebsd-security@, and > > > freebsd-stable@. Please forgive me if crossposting is frowned upon.] > > > > > > Address Space Layout Randomization, or ASLR for short, is an exploit > > > mitigation technology. It helps secure applications against low-level > > > exploits. A popular secure implementation is known as PaX ASLR, which is > > > a third-party patch for Linux. Our implementation is based off of PaX's. > > > > > > Oliver Pinter, Danilo Egea, and I have been working hard to bring more > > > features and robust stability to our ASLR patches. We've done extensive > > > testing on amd64. We'd like to get as many people testing these patches. > > > Given the nature of them, we'd also like as many eyeballs reviewing the > > > code as well. > > > > > > I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on > > > the RPI), when a parent forks a child, and the child gracefully exits, > > > the parent segfaults with the pc register pointing to 0xc000. That > > > address is always the same, no matter the application. If anyone knows > > > the ARM architecture well, and how FreeBSD ties into it, I'd like a > > > little guidance. > > > > > > I also have a sparc64 box, but I'm having trouble getting a vanilla > > > 11-current system to be stable on it. I ought to file a few PRs. > > > > > > You can find links to the patches below. > > > > > > Patch for 11-current: > > > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff > > > > > > Patch for 10-stable: > > > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff > > > > > > > Shawn > > > > I appreciate you working on this. We must have this in FreeBSD. > > > > I looked at the patch and I read, but not run it. Comments below. > > > > My personal opinion is that kern_pax.c should be compiled in by default. If > > it adds a lot of size, it'd be better to provide empty stub calls instead of > > #ifdef'ing everything. But security is very important especially in > > embeddded systems, so you can imagine you're writing the code that everybody > > wants and must have enabled for decent level of security. > > > > All modern systems run with ASLR turned on. > > > > I skipped user-space stuff. I don't think it's necessary in this commit and > > should be separated. > > > > There's a lot of lines of code for status showing. Not sure if we care that > > much: ASLR is either on or off. Not sure about more granularity. More below. > > We provide the level of granularity because there are a lot of > applications that might exhibit weird behaviors or even crash if we > randomize too many bits. We provide sane defaults, but allow each user > to choose the level of security versus the level of stability they > desire. I'm OK with it being more granular if that's the case. But Linux/MacOSX all have ASLR. If we have programs in ports/ that run on Linux, it's likely they'll just work. If they break, we'll just marked them as broken and to be fixed by the maintainer. Can you run GNOME or KDE with your patch? Or node.js? Node.js uses JIT engine for Javascript. If it works, it's quite likely other will work. > > > > kern_jail.c: > > > > something looks wrong here. Sounds like you need "pr->pax". But I don't > > understand why you need to have these pr_* values here. It seems > > unnecessary. > > I've made it possible to have per-jail ASLR settings. If you have an > application that misbehaves, you can jail it with ASLR turned off just > for that jail. My BSDCan presentation talks about this. The recording > isn't up, yet, though. I don't get it. If there's a program that is broken but you want to run it in jail, our rc.d jail startup script should earn a "NOPIE" function maybe. I believed PIE/NOPIE is per-process setting on whether to use PIE or not. In this case we'd be able to do: /usr/sbin/jail .. /usr/sbin/nopax program ... In Linux you can do it with personalities. I don't know what it would translate in the FreeBSD to. I guess this could be achieved with simple per-process SYSCTL. "nopax" would disable ASLR, fork and exec(). > > I can imagine we won't want ASLR only temporarily, for ports which break and > > must be fixed. So we probably just need per-process ASLR on/off switch and a > > wrapper which could be used like: > > > > aslr off program > > So we have right now an addition to mac_bsdextended(4)/ugidfw(8) that > does this exact thing. We also plan on adding FS extended attribute > support soon, too. Also, per-jail ASLR settings. If you can already do it with MAC layer, it should be enough. Touching jail(8) will require lots of people to review this pa
Re: ipmi patch for review
On 5/30/14, 10:44 AM, Doug Ambrisko wrote: On Thu, Sep 19, 2013 at 03:04:46PM -0400, John Baldwin wrote: | On Tuesday, September 17, 2013 6:21:10 am Gleb Smirnoff wrote: | > Hi! | > | > When system is writing a kernel core dump, it issues watchdog | > pat wdog_kern_pat(WD_LASTVAL). If ipmi is in action, it registers | > ipmi_wd_event() as event for watchdog. Thus ipmi_wd_event() is | > called in dumping context. | > | > The problem is that ipmi_wd_event() calls into ipmi_set_watchdog(), | > that calls into ipmi_alloc_request(), which uses M_WAITOK and | > thus sleeps. This is a smaller problem, since can be converted to | > M_NOWAIT. But ipmi_set_watchdog() then calls into | > ipmi_submit_driver_request(), which calls msleep() any time. | > | > The attached patch allows me to successfully write cores in | > presence of IPMI. | | Of course, the watchdog might go off during your dump. :) | | The real fix is more complicated, which is that we should not use | a worker thread for at least SMIC and KCS. I haven't looked at this patch but I have local code that switches KCS into polling direct mode when the kernel goes into panic mode. I use this to write Linux compatible back traces into the system event logs. This could allow the watchdogd to continue to work. This should be easily extended to SMIC mode. SMBUS would be harder but at a prior company I made the SMBIO driver work in polled mode. If someone wants to look at this I can post the changes for KCS and the kernel backtrace to the system event log. We find this useful when looking at customer machines. IPMI gets upset if things get intermixed/interrupted so there needs to be serialization and cancellation if being interrupted. These patches would be really nice to have in base. I noticed this problem too, you can't really touch watchdogs some of the time when in a panic(9) situation and it leaves you in a bad state to stop them or reset them while you are dumping. Thank you for looking at this. -Alfred ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RES: Thread Scheduler Priority
Any clue on this ? :(
-Mensagem original-
De: owner-freebsd-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] Em nome de Fred Pedrisa
Enviada em: quinta-feira, 29 de maio de 2014 02:19
Para: 'Adrian Chadd'
Cc: 'freebsd-current'
Assunto: RES: Thread Scheduler Priority
Hello,
Yes.
-Mensagem original-
De: owner-freebsd-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] Em nome de Adrian Chadd Enviada
em: quinta-feira, 29 de maio de 2014 02:18
Para: Fred Pedrisa
Cc: freebsd-current
Assunto: Re: Thread Scheduler Priority
are you doing this all as root?
-a
On 28 May 2014 22:12, Fred Pedrisa wrote:
> Hi, Guys.
>
>
>
> How can I adjust a certain thread to have the maximum system priority
> in the scheduler ?
>
>
>
> I've tried doing it this way :
>
>
>
>/* Set thread priority.
> */
>
>if
> (pthread_getschedparam(ts[gnThreadID], &police, ¶m[gnThreadID]) !=
> 0)
>
>{
>
>error
> ("Unable to get priority");
>
>return
> 1;
>
>}
>
>
> param[gnThreadID].sched_priority = 99;
>
>if
> (pthread_setschedparam(ts[gnThreadID], police, ¶m[gnThreadID]) !=
> 0)
>
>{
>
> error("Unable to set priority");
>
> return 1;
>
>}
>
>
>
> However, in 'top', I don't see the process threads switching to -92
> priority, like other threads in the system, is something I did wrong
> or maybe I might be missing something ?
>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Thread Scheduler Priority
On Thu, 2014-05-29 at 02:12 -0300, Fred Pedrisa wrote:
> Hi, Guys.
>
>
>
> How can I adjust a certain thread to have the maximum system priority in the
> scheduler ?
>
>
>
> I've tried doing it this way :
>
>
>
>/* Set thread priority. */
>
>if
> (pthread_getschedparam(ts[gnThreadID], &police, ¶m[gnThreadID]) != 0)
>
>{
>
>error
> ("Unable to get priority");
>
>return 1;
>
>}
>
>
> param[gnThreadID].sched_priority = 99;
>
>if
> (pthread_setschedparam(ts[gnThreadID], police, ¶m[gnThreadID]) != 0)
>
>{
>
> error("Unable to set priority");
>
> return 1;
>
>}
>
>
>
> However, in 'top', I don't see the process threads switching to -92
> priority, like other threads in the system, is something I did wrong or
> maybe I might be missing something ?
You can't just set the priority to any number you want... per the man
page for pthread_setschedparam() the value has to fall within the ranges
returned by sched_get_priority_min() and sched_get_priority_max() for
the given scheduling class. On freebsd those ranges are 0-31.
I suspect from your statement of wanting "maximum system priority" maybe
what you need to do is change the scheduling class from SCHED_OTHER to
SCHED_RR, that should give you realtime priority. Be aware that a
realtime thread that is compute-bound will take over the system (or one
core on an SMP system); it will get all cycles if it is always runnable.
If what you're looking for is the thread equivelent of using the nice
command, so that you give a boost to a thread over other threads in the
timeshare (SCHED_OTHER) scheduling class, there is currently no way to
do that in freebsd.
Last year for $work I about went crazy trying to figure out the mapping
between pthread scheduling classes and priorities and freebsd's idea of
thread prorities. I eventually gave up on the pthread API and used the
freebsd native function rtprio_thread() instead.
-- Ian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RES: Thread Scheduler Priority
Hello,
This is 'min' and 'max' for the default policy :
Min : 0, Max : 103
In my system.
-Mensagem original-
De: owner-freebsd-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] Em nome de Ian Lepore
Enviada em: sexta-feira, 30 de maio de 2014 23:50
Para: Fred Pedrisa
Cc: 'freebsd-current'
Assunto: Re: Thread Scheduler Priority
On Thu, 2014-05-29 at 02:12 -0300, Fred Pedrisa wrote:
> Hi, Guys.
>
>
>
> How can I adjust a certain thread to have the maximum system priority
> in the scheduler ?
>
>
>
> I've tried doing it this way :
>
>
>
>/* Set thread priority.
> */
>
>if
> (pthread_getschedparam(ts[gnThreadID], &police, ¶m[gnThreadID]) !=
> 0)
>
>{
>
>error
> ("Unable to get priority");
>
>return
> 1;
>
>}
>
>
> param[gnThreadID].sched_priority = 99;
>
>if
> (pthread_setschedparam(ts[gnThreadID], police, ¶m[gnThreadID]) !=
> 0)
>
>{
>
> error("Unable to set priority");
>
> return 1;
>
>}
>
>
>
> However, in 'top', I don't see the process threads switching to -92
> priority, like other threads in the system, is something I did wrong
> or maybe I might be missing something ?
You can't just set the priority to any number you want... per the man page
for pthread_setschedparam() the value has to fall within the ranges returned
by sched_get_priority_min() and sched_get_priority_max() for the given
scheduling class. On freebsd those ranges are 0-31.
I suspect from your statement of wanting "maximum system priority" maybe
what you need to do is change the scheduling class from SCHED_OTHER to
SCHED_RR, that should give you realtime priority. Be aware that a realtime
thread that is compute-bound will take over the system (or one core on an
SMP system); it will get all cycles if it is always runnable.
If what you're looking for is the thread equivelent of using the nice
command, so that you give a boost to a thread over other threads in the
timeshare (SCHED_OTHER) scheduling class, there is currently no way to do
that in freebsd.
Last year for $work I about went crazy trying to figure out the mapping
between pthread scheduling classes and priorities and freebsd's idea of
thread prorities. I eventually gave up on the pthread API and used the
freebsd native function rtprio_thread() instead.
-- Ian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
