Re: How to enable more than 256 pty's?
Any one got any pointers on this, the machine we running this app on is over 90% idle so I really don't want to have to install a second machine just to workaround a limit on the number of pty's, surely there's a way to increase this? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to enable more than 256 pty's?
"Steven Hartland" <[EMAIL PROTECTED]> writes:
> Any one got any pointers on this, the machine we running this app on is over
> 90% idle so I really don't want to have to install a second machine just to
> workaround a limit on the number of pty's, surely there's a way to increase
> this?
You need to change the way ptys are named in pty_create_slave() and
pty_clone() in sys/kern/tty_pty.c. Just changing names won't help as
the sequence is also hardcoded in pty_clone().
You also need to change grantpt(), openpty() and any other userland code
which has hardcoded knowledge of the naming scheme:
[EMAIL PROTECTED] ~% gfs pqrsPQRS
src/sys/kern/tty_pty.c: static char *names = "pqrsPQRS";
src/sys/kern/tty_pty.c: * pts ==
/dev/tty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
src/sys/kern/tty_pty.c: * ptc ==
/dev/pty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
src/contrib/telnet/telnetd/sys_term.c: for (cp = "pqrsPQRS"; *cp; cp++) {
src/usr.sbin/ac/ac.c: strchr("pqrsPQRS",
usr.ut_line[3]) != 0 ||
src/lib/libutil/pty.c: for (cp1 = "pqrsPQRS"; *cp1; cp1++) {
src/lib/libc/stdlib/grantpt.c: #define PT_DEV1 "pqrsPQRS"
Alternatively, set kern.pts.enable to 1, and find and fix the
hang-on-close bug in the pts code (if it hasn't been fixed already)
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to enable more than 256 pty's?
On Tue, Oct 02, 2007 at 02:05:03PM +0200, Dag-Erling Smørgrav wrote:
> "Steven Hartland" <[EMAIL PROTECTED]> writes:
> > Any one got any pointers on this, the machine we running this app on is over
> > 90% idle so I really don't want to have to install a second machine just to
> > workaround a limit on the number of pty's, surely there's a way to increase
> > this?
>
> You need to change the way ptys are named in pty_create_slave() and
> pty_clone() in sys/kern/tty_pty.c. Just changing names won't help as
> the sequence is also hardcoded in pty_clone().
>
> You also need to change grantpt(), openpty() and any other userland code
> which has hardcoded knowledge of the naming scheme:
>
> [EMAIL PROTECTED] ~% gfs pqrsPQRS
> src/sys/kern/tty_pty.c: static char *names = "pqrsPQRS";
> src/sys/kern/tty_pty.c: * pts ==
> /dev/tty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
> src/sys/kern/tty_pty.c: * ptc ==
> /dev/pty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
> src/contrib/telnet/telnetd/sys_term.c: for (cp = "pqrsPQRS"; *cp; cp++) {
> src/usr.sbin/ac/ac.c: strchr("pqrsPQRS",
> usr.ut_line[3]) != 0 ||
> src/lib/libutil/pty.c: for (cp1 = "pqrsPQRS"; *cp1; cp1++) {
> src/lib/libc/stdlib/grantpt.c: #define PT_DEV1 "pqrsPQRS"
>
> Alternatively, set kern.pts.enable to 1, and find and fix the
> hang-on-close bug in the pts code (if it hasn't been fixed already)
This last option is only available if you are running 7-CURRENT though.
The pts code is not in 6-STABLE (or older.)
--
Erik Trulsson
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to enable more than 256 pty's?
Vlad GALU <[EMAIL PROTECTED]> writes: > Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > > Alternatively, set kern.pts.enable to 1, and find and fix the > > hang-on-close bug in the pts code (if it hasn't been fixed already) > Looks like it hasn't been. A friend who tried to set up an access > server for his company stumbled upon it. kib@ says it has as of sys/kern/tty_pts.c rev 1.15 (2007-07-03). Has your friend tried with a sufficiently recent kernel? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to enable more than 256 pty's?
On 10/2/07, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > Vlad GALU <[EMAIL PROTECTED]> writes: > > Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > > > Alternatively, set kern.pts.enable to 1, and find and fix the > > > hang-on-close bug in the pts code (if it hasn't been fixed already) > > Looks like it hasn't been. A friend who tried to set up an access > > server for his company stumbled upon it. > > kib@ says it has as of sys/kern/tty_pts.c rev 1.15 (2007-07-03). Has > your friend tried with a sufficiently recent kernel? I can't tell for sure, he tried a week or two ago, with a recent snapshot. I forwarded him your mail, I hope he'll retry and get back to me. > > DES > -- > Dag-Erling Smørgrav - [EMAIL PROTECTED] > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to enable more than 256 pty's?
On 10/2/07, Vlad GALU <[EMAIL PROTECTED]> wrote: > On 10/2/07, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > > Vlad GALU <[EMAIL PROTECTED]> writes: > > > Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > > > > Alternatively, set kern.pts.enable to 1, and find and fix the > > > > hang-on-close bug in the pts code (if it hasn't been fixed already) > > > Looks like it hasn't been. A friend who tried to set up an access > > > server for his company stumbled upon it. > > > > kib@ says it has as of sys/kern/tty_pts.c rev 1.15 (2007-07-03). Has > > your friend tried with a sufficiently recent kernel? > >I can't tell for sure, he tried a week or two ago, with a recent > snapshot. I forwarded him your mail, I hope he'll retry and get back > to me. > The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. > > > > DES > > -- > > Dag-Erling Smørgrav - [EMAIL PROTECTED] > > > > > -- > If it's there, and you can see it, it's real. > If it's not there, and you can see it, it's virtual. > If it's there, and you can't see it, it's transparent. > If it's not there, and you can't see it, you erased it. > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to enable more than 256 pty's?
On 10/2/07, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote:
> "Steven Hartland" <[EMAIL PROTECTED]> writes:
> > Any one got any pointers on this, the machine we running this app on is over
> > 90% idle so I really don't want to have to install a second machine just to
> > workaround a limit on the number of pty's, surely there's a way to increase
> > this?
>
> You need to change the way ptys are named in pty_create_slave() and
> pty_clone() in sys/kern/tty_pty.c. Just changing names won't help as
> the sequence is also hardcoded in pty_clone().
>
> You also need to change grantpt(), openpty() and any other userland code
> which has hardcoded knowledge of the naming scheme:
>
> [EMAIL PROTECTED] ~% gfs pqrsPQRS
> src/sys/kern/tty_pty.c: static char *names = "pqrsPQRS";
> src/sys/kern/tty_pty.c: * pts ==
> /dev/tty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
> src/sys/kern/tty_pty.c: * ptc ==
> /dev/pty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
> src/contrib/telnet/telnetd/sys_term.c: for (cp = "pqrsPQRS"; *cp; cp++) {
> src/usr.sbin/ac/ac.c: strchr("pqrsPQRS",
> usr.ut_line[3]) != 0 ||
> src/lib/libutil/pty.c: for (cp1 = "pqrsPQRS"; *cp1; cp1++) {
> src/lib/libc/stdlib/grantpt.c: #define PT_DEV1 "pqrsPQRS"
>
> Alternatively, set kern.pts.enable to 1, and find and fix the
> hang-on-close bug in the pts code (if it hasn't been fixed already)
Looks like it hasn't been. A friend who tried to set up an access
server for his company stumbled upon it.
>
> DES
> --
> Dag-Erling Smørgrav - [EMAIL PROTECTED]
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
--
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to enable more than 256 pty's?
"Vlad GALU" <[EMAIL PROTECTED]> writes: > The symptoms were exhibited even with rev. 1.16. I've CC'ed him so > he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to enable more than 256 pty's?
On 10/2/07, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > "Vlad GALU" <[EMAIL PROTECTED]> writes: > > The symptoms were exhibited even with rev. 1.16. I've CC'ed him so > > he can catch up with the thread. > > Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. > > DES > -- > Dag-Erling Smørgrav - [EMAIL PROTECTED] > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to enable more than 256 pty's?
"Vlad GALU" <[EMAIL PROTECTED]> writes: > Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > > "Vlad GALU" <[EMAIL PROTECTED]> writes: > > > The symptoms were exhibited even with rev. 1.16. I've CC'ed him so > > > he can catch up with the thread. > > Which symptoms? I can no longer reproduce the hang-on-close bug. > Strangely enough, me neither. In his case, allocated pts' wouldn't get > deallocated once the sessions ended. Wouldn't get deallocated right away, or wouldn't get deallocated at all? Apparently, it is not unusual for pts reclamation to be delayed a bit by a non-zero refcnt. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to enable more than 256 pty's?
On 10/2/07, Vlad GALU <[EMAIL PROTECTED]> wrote: > On 10/2/07, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > > "Vlad GALU" <[EMAIL PROTECTED]> writes: > > > The symptoms were exhibited even with rev. 1.16. I've CC'ed him so > > > he can catch up with the thread. > > > > Which symptoms? I can no longer reproduce the hang-on-close bug. > >Strangely enough, me neither. In his case, allocated pts' wouldn't > get deallocated once the sessions ended. > > However, I see that, if I use pts/0-7, for instance, then log off pts/7, the next assigned pts will be pts/8. Is this expected? I tried lowering kern.pts.max to 20. If I open 20 of them and close them afterwards, on the next try I get "no more ptys" from my screen. > > DES > > -- > > Dag-Erling Smørgrav - [EMAIL PROTECTED] > > > > > -- > If it's there, and you can see it, it's real. > If it's not there, and you can see it, it's virtual. > If it's there, and you can't see it, it's transparent. > If it's not there, and you can't see it, you erased it. > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to enable more than 256 pty's?
* Vlad GALU <[EMAIL PROTECTED]> wrote: > On 10/2/07, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > > "Vlad GALU" <[EMAIL PROTECTED]> writes: > > > The symptoms were exhibited even with rev. 1.16. I've CC'ed him so > > > he can catch up with the thread. > > > > Which symptoms? I can no longer reproduce the hang-on-close bug. > >Strangely enough, me neither. In his case, allocated pts' wouldn't > get deallocated once the sessions ended. This is a known issue IIRC. See line 245 of tty_pts.c 1.16. Can be easily reproduced by killing the sshd while apps are still running in the shell. I thought we weren't able to destroy the device there, because you can't destroy a TTY when it is used by an application (i.e. when it's the controlling terminal). -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://g-rave.nl/ pgpuvEtLMzJFq.pgp Description: PGP signature
Re: How to enable more than 256 pty's?
On 10/2/07, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > "Vlad GALU" <[EMAIL PROTECTED]> writes: > > Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > > > "Vlad GALU" <[EMAIL PROTECTED]> writes: > > > > The symptoms were exhibited even with rev. 1.16. I've CC'ed him so > > > > he can catch up with the thread. > > > Which symptoms? I can no longer reproduce the hang-on-close bug. > > Strangely enough, me neither. In his case, allocated pts' wouldn't get > > deallocated once the sessions ended. > > Wouldn't get deallocated right away, or wouldn't get deallocated at all? > Apparently, it is not unusual for pts reclamation to be delayed a bit by > a non-zero refcnt. > As per my other mail, they wouldn't get deallocated at all. They still show up in /dev/pts/ even after closing, and the next integer index is picked up upon the next terminal creation. > DES > -- > Dag-Erling Smørgrav - [EMAIL PROTECTED] > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to enable more than 256 pty's?
* Ed Schouten <[EMAIL PROTECTED]> wrote: > * Vlad GALU <[EMAIL PROTECTED]> wrote: > > On 10/2/07, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > > > "Vlad GALU" <[EMAIL PROTECTED]> writes: > > > > The symptoms were exhibited even with rev. 1.16. I've CC'ed him so > > > > he can catch up with the thread. > > > > > > Which symptoms? I can no longer reproduce the hang-on-close bug. > > > >Strangely enough, me neither. In his case, allocated pts' wouldn't > > get deallocated once the sessions ended. > > This is a known issue IIRC. See line 245 of tty_pts.c 1.16. Can be > easily reproduced by killing the sshd while apps are still running in > the shell. > > I thought we weren't able to destroy the device there, because you can't > destroy a TTY when it is used by an application (i.e. when it's the > controlling terminal). Thought about this 2 seconds after I sent my message: this is also responsible for the `zombie jails': tty's are made with make_dev_cred, which causes ucred's to be leaked, which eventually causes prisons to be leaked. -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://g-rave.nl/ pgpcwewwdcX4k.pgp Description: PGP signature
Re: How to enable more than 256 pty's?
Ed Schouten <[EMAIL PROTECTED]> writes: > This is a known issue IIRC. See line 245 of tty_pts.c 1.16. Can be > easily reproduced by killing the sshd while apps are still running in > the shell. It's not that simple. The question is why t_refcnt > 1 when there are no processes left attached to the tty. I managed to reproduce this as follows: $ script -q 1 script -q 2 script -q 3 script -q 4 tty if nothing else is going on at the same time, you should always see the same output, but instead you see a steadily increasing pts number. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to enable more than 256 pty's?
Thanks for the tip there but I cant find any function called pty_create_slave
in the source.
N.B. Machine is running 5.4 but I also looked on 6.2 which we could upgrade
to but still couldn't find it, so I assume you may be talking about something
that's in current which we couldn't risk on this machine.
Is this something that's possible on 5.x / 6.2 or something that will need a
lot of work?
Regards
Steve
- Original Message -
From: "Dag-Erling Smørgrav" <[EMAIL PROTECTED]>
You need to change the way ptys are named in pty_create_slave() and
pty_clone() in sys/kern/tty_pty.c. Just changing names won't help as
the sequence is also hardcoded in pty_clone().
You also need to change grantpt(), openpty() and any other userland code
which has hardcoded knowledge of the naming scheme:
[EMAIL PROTECTED] ~% gfs pqrsPQRS
src/sys/kern/tty_pty.c: static char *names = "pqrsPQRS";
src/sys/kern/tty_pty.c: * pts ==
/dev/tty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
src/sys/kern/tty_pty.c: * ptc ==
/dev/pty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
src/contrib/telnet/telnetd/sys_term.c: for (cp = "pqrsPQRS"; *cp; cp++) {
src/usr.sbin/ac/ac.c: strchr("pqrsPQRS",
usr.ut_line[3]) != 0 ||
src/lib/libutil/pty.c: for (cp1 = "pqrsPQRS"; *cp1; cp1++) {
src/lib/libc/stdlib/grantpt.c: #define PT_DEV1 "pqrsPQRS"
Alternatively, set kern.pts.enable to 1, and find and fix the
hang-on-close bug in the pts code (if it hasn't been fixed already)
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please
telephone +44 845 868 1337
or return the E.mail to [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Comtrol RocketPort 550 uPCI, 16-port
>> Hi. First off, to get it out of the way, I work for Comtrol. This is a >> Comtrol GMBH (used to be Comtrol UK, now Comtrol GMBH [Switzerland]) >> product. The two are separate companies now. Anyhow, if you have had >> this card for less than 30 days, I would hi,ghly recommend returning it >> to the distributor for a RocketPort uPCI 16 port card, as this is a >> Comtrol U.S. product and we have a 6.2 driver for our entire RocketPort >> line. >Thanks for the info. Is the external box with the RJ-45 serial ports >(part # 99420-6) compatible with the Comtrol US card you're about to >send the link for, or would I need to send that back as well? You can hang onto the interface, it's compatible with both the RocketPort 550 uPCI 16p as well as the RocketPort uPCI 16p. Here is the link to the page about the RocketPort uPCI 16p: http://www.comtrol.com/products/specifications/99355-1 >> other Unices guy in tech support at Comtrol U.S. and I would definitely >> like to extend an invitation for anyone who would like a copy of the >> driver to email me at my work address >Does this mean that the US card is not supported by the rp driver that >comes with FreeBSD 6.2, or was that mostly aimed at folks who run an >OS (version) that doesn't include a driver? > >Thanks again, >Jeff What that meant was that the driver that comes with FreeBSD 6.2 is an older version of the driver. (Much older, 8 years older I believe.) I've heard from folks who've had success with the driver that comes with 6.2 with certain cards, and heard from folks who've had success after hacking the code a bit with other cards. Either way, I am trying to get things to a point that our FreeBSD customers can be confident that their cards will be supported now, and into the future. When I arrived here, the last release was for FreeBSD 5.3: ftp://ftp.comtrol.com/rport/drivers/u_pci/freebsd/5_x/1800255a.tgz Since I personally run FreeBSD at home, and can see the value in keeping our drivers up to date with the current release, I wanted to get things up to date. I put in an engineering request for a 6.x driver, and we have it now. It's in the beta phase, and we have beta customers running it with no complaints at the moment. I will have to put the link up into this thread once it gets uploaded to the ftp server, which should be by the end of the week. Regards, Nick Nick Thompson Technical Support Specialist [EMAIL PROTECTED] Comtrol Corporation ftp://ftp.comtrol.com 6655 Wedgwood Rd. Ste 120 http://www.comtrol.com Maple Grove, MN. 55311 Sales: (800)GO-ROCKET ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Critical Sections for userland.
Hi guys, we need critical sections for userland here. This is basically to avoid a process being switched out while holding a user level spinlock. The way I envisioned doing this was as follows: 1) syscall that sets a pointer in the struct thread. 2) user mlocks that page. 3) when scheduler goes to switch out a process due to quantum it checks this pointer, if set it will give the process more time to run and not switch it out. (*) 4) the load would seem to have to be non-faulting. So my questions are: 1) Where would be a good place to add this code in the scheduler and how? 2) How does one do a read/write to userland address, but if the access would fault, then return an error rather than trap? I'm quite sure the scheduling decisions would be made inside of the timer interrupt, (am I right?), and hence would not be allowed to fault in pages. (*) Note, we will implement limits to this so that a haywire application is not able to be "critical" forever. Any help would be appreciated. -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
On Tue, 2 Oct 2007, Alfred Perlstein wrote: Hi guys, we need critical sections for userland here. This is basically to avoid a process being switched out while holding a user level spinlock. Setting the scheduling class to real-time and using SCHED_FIFO and adjusting the thread priority around the lock doesn't work? -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Daniel Eischen <[EMAIL PROTECTED]> [071002 19:46] wrote: > On Tue, 2 Oct 2007, Alfred Perlstein wrote: > > >Hi guys, we need critical sections for userland here. > > > >This is basically to avoid a process being switched out while holding > >a user level spinlock. > > Setting the scheduling class to real-time and using SCHED_FIFO > and adjusting the thread priority around the lock doesn't work? Too heavy weight, we want to basically have this sort of code in userland: /* assume single threaded process for now */ static int is_critical; atomic_mutex_lock(); /* implies ++is_critical */ ...do stuff... atomic_mutex_unlock(); /* implies --is_critical */ We don't want two or more syscalls per lock operation. :) -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
On Tue, 2 Oct 2007, Alfred Perlstein wrote: * Daniel Eischen <[EMAIL PROTECTED]> [071002 19:46] wrote: On Tue, 2 Oct 2007, Alfred Perlstein wrote: Hi guys, we need critical sections for userland here. This is basically to avoid a process being switched out while holding a user level spinlock. Setting the scheduling class to real-time and using SCHED_FIFO and adjusting the thread priority around the lock doesn't work? Too heavy weight, we want to basically have this sort of code in userland: Well, yeah, but are you _really_ sure that you aren't just running something that should be real-time and have priority over other applications? SCHED_FIFO means you will run until you relinquish the CPU (you can only do this as root). If all your threads are well behaved, would this work? Have you tried it? Are you trying to prevent switching out of the thread amongst other threads of the same application, or all threads in the system? -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Kip Macy <[EMAIL PROTECTED]> [071002 20:00] wrote: > On 10/2/07, Alfred Perlstein <[EMAIL PROTECTED]> wrote: > > * Daniel Eischen <[EMAIL PROTECTED]> [071002 19:46] wrote: > > > On Tue, 2 Oct 2007, Alfred Perlstein wrote: > > > > > > >Hi guys, we need critical sections for userland here. > > > > > > > >This is basically to avoid a process being switched out while holding > > > >a user level spinlock. > > > > > > Setting the scheduling class to real-time and using SCHED_FIFO > > > and adjusting the thread priority around the lock doesn't work? > > > > Too heavy weight, we want to basically have this sort of code > > in userland: > > > > /* assume single threaded process for now */ > > static int is_critical; > > > > > > > > atomic_mutex_lock(); /* implies ++is_critical */ > > ...do stuff... > > atomic_mutex_unlock(); /* implies --is_critical */ > > > > We don't want two or more syscalls per lock operation. :) > > > I assume these processes are running as root? There is nothing to > prevent the process from never dropping the lock. Yes there is... The part that I ommitted detailed keeping a count of the number of times this happens and if it exceeds a threshold then killing the process. Additionally, the kernel would write a byte into the user shared area indicating, "please call me because you need to yield after you're done with your critical section", if the kernel is not listened to, then we beat the process with a rusty tire iron. Sheesh, now can I get some help with this? If I wanted this kind of treatment, I'd be asking on irc! :) -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Daniel Eischen <[EMAIL PROTECTED]> [071002 20:02] wrote: > On Tue, 2 Oct 2007, Alfred Perlstein wrote: > > >* Daniel Eischen <[EMAIL PROTECTED]> [071002 19:46] wrote: > >>On Tue, 2 Oct 2007, Alfred Perlstein wrote: > >> > >>>Hi guys, we need critical sections for userland here. > >>> > >>>This is basically to avoid a process being switched out while holding > >>>a user level spinlock. > >> > >>Setting the scheduling class to real-time and using SCHED_FIFO > >>and adjusting the thread priority around the lock doesn't work? > > > >Too heavy weight, we want to basically have this sort of code > >in userland: > > Well, yeah, but are you _really_ sure that you aren't just > running something that should be real-time and have priority > over other applications? SCHED_FIFO means you will run until > you relinquish the CPU (you can only do this as root). If > all your threads are well behaved, would this work? Have > you tried it? No, because it wouldn't work. How do we know when to let go of the cpu? In my system, the kernel tells you without polling. > > Are you trying to prevent switching out of the thread > amongst other threads of the same application, or all > threads in the system? All threads on that CPU. It's basically, almost like a "soft spl" for userland. Right? -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
On Tue, 2 Oct 2007, Alfred Perlstein wrote: * Daniel Eischen <[EMAIL PROTECTED]> [071002 20:02] wrote: On Tue, 2 Oct 2007, Alfred Perlstein wrote: * Daniel Eischen <[EMAIL PROTECTED]> [071002 19:46] wrote: On Tue, 2 Oct 2007, Alfred Perlstein wrote: Hi guys, we need critical sections for userland here. This is basically to avoid a process being switched out while holding a user level spinlock. Setting the scheduling class to real-time and using SCHED_FIFO and adjusting the thread priority around the lock doesn't work? Too heavy weight, we want to basically have this sort of code in userland: Well, yeah, but are you _really_ sure that you aren't just running something that should be real-time and have priority over other applications? SCHED_FIFO means you will run until you relinquish the CPU (you can only do this as root). If all your threads are well behaved, would this work? Have you tried it? No, because it wouldn't work. How do we know when to let go of the cpu? In my system, the kernel tells you without polling. You don't have to know when to "let go of the cpu" if your threads are well behaved (meaning they block on some event, or have periods when they wait). They will let go of the CPU normally. When they're busy, they will not be switched out (unless perhaps there is an interrupt thread that needs to run -- I'm not sure how real-time threads get scheduled against ithreads). If your threads are not well behaved (CPU hogs), then that isn't going to work because they'll probably bog down the system. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Daniel Eischen <[EMAIL PROTECTED]> [071002 20:16] wrote: > On Tue, 2 Oct 2007, Alfred Perlstein wrote: > > >* Daniel Eischen <[EMAIL PROTECTED]> [071002 20:02] wrote: > >>On Tue, 2 Oct 2007, Alfred Perlstein wrote: > >> > >>>* Daniel Eischen <[EMAIL PROTECTED]> [071002 19:46] wrote: > On Tue, 2 Oct 2007, Alfred Perlstein wrote: > > >Hi guys, we need critical sections for userland here. > > > >This is basically to avoid a process being switched out while holding > >a user level spinlock. > > Setting the scheduling class to real-time and using SCHED_FIFO > and adjusting the thread priority around the lock doesn't work? > >>> > >>>Too heavy weight, we want to basically have this sort of code > >>>in userland: > >> > >>Well, yeah, but are you _really_ sure that you aren't just > >>running something that should be real-time and have priority > >>over other applications? SCHED_FIFO means you will run until > >>you relinquish the CPU (you can only do this as root). If > >>all your threads are well behaved, would this work? Have > >>you tried it? > > > >No, because it wouldn't work. How do we know when to let go > >of the cpu? In my system, the kernel tells you without polling. > > You don't have to know when to "let go of the cpu" if your > threads are well behaved (meaning they block on some event, > or have periods when they wait). They will let go of the > CPU normally. When they're busy, they will not be switched > out (unless perhaps there is an interrupt thread that needs > to run -- I'm not sure how real-time threads get scheduled > against ithreads). > > If your threads are not well behaved (CPU hogs), then that > isn't going to work because they'll probably bog down the > system. Yes, I know how threading works. Unfortunately, your solution is not workable for us. thank you, -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
On 10/2/07, Daniel Eischen <[EMAIL PROTECTED]> wrote: > On Tue, 2 Oct 2007, Alfred Perlstein wrote: > > > * Daniel Eischen <[EMAIL PROTECTED]> [071002 20:02] wrote: > >> On Tue, 2 Oct 2007, Alfred Perlstein wrote: > >> > >>> * Daniel Eischen <[EMAIL PROTECTED]> [071002 19:46] wrote: > On Tue, 2 Oct 2007, Alfred Perlstein wrote: > > > Hi guys, we need critical sections for userland here. > > > > This is basically to avoid a process being switched out while holding > > a user level spinlock. > > Setting the scheduling class to real-time and using SCHED_FIFO > and adjusting the thread priority around the lock doesn't work? > >>> > >>> Too heavy weight, we want to basically have this sort of code > >>> in userland: > >> > >> Well, yeah, but are you _really_ sure that you aren't just > >> running something that should be real-time and have priority > >> over other applications? SCHED_FIFO means you will run until > >> you relinquish the CPU (you can only do this as root). If > >> all your threads are well behaved, would this work? Have > >> you tried it? > > > > No, because it wouldn't work. How do we know when to let go > > of the cpu? In my system, the kernel tells you without polling. > > You don't have to know when to "let go of the cpu" if your > threads are well behaved (meaning they block on some event, > or have periods when they wait). They will let go of the > CPU normally. When they're busy, they will not be switched > out (unless perhaps there is an interrupt thread that needs > to run -- I'm not sure how real-time threads get scheduled > against ithreads). > > If your threads are not well behaved (CPU hogs), then that > isn't going to work because they'll probably bog down the > system. > See /sys/priority.h realtime is right below ithreads in terms of priority. One of the big motivations for gang scheduling and part of the reason why SMP guests often perform poorly is that apps / VMs don't scale well if they're descheduled from the cpu while holding a lock. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
On 10/2/07, Alfred Perlstein <[EMAIL PROTECTED]> wrote: > * Daniel Eischen <[EMAIL PROTECTED]> [071002 19:46] wrote: > > On Tue, 2 Oct 2007, Alfred Perlstein wrote: > > > > >Hi guys, we need critical sections for userland here. > > > > > >This is basically to avoid a process being switched out while holding > > >a user level spinlock. > > > > Setting the scheduling class to real-time and using SCHED_FIFO > > and adjusting the thread priority around the lock doesn't work? > > Too heavy weight, we want to basically have this sort of code > in userland: > > /* assume single threaded process for now */ > static int is_critical; > > > > atomic_mutex_lock(); /* implies ++is_critical */ > ...do stuff... > atomic_mutex_unlock(); /* implies --is_critical */ > > We don't want two or more syscalls per lock operation. :) I assume these processes are running as root? There is nothing to prevent the process from never dropping the lock. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Kip Macy <[EMAIL PROTECTED]> [071002 20:24] wrote: > See /sys/priority.h realtime is right below ithreads in terms of > priority. One of the big motivations for gang scheduling and part of > the reason why SMP guests often perform poorly is that apps / VMs > don't scale well if they're descheduled from the cpu while holding a > lock. Yes, exactly the problem, it sucks when process A on CPU 1 runs out of quantum while holding a lock that a runner on CPU 2 wants. -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to enable more than 256 pty's?
"Steven Hartland" <[EMAIL PROTECTED]> writes: > Thanks for the tip there but I cant find any function called pty_create_slave > in the source. Just grep your source tree for occurrences of pqrsPQRS. > Is this something that's possible on 5.x / 6.2 or something that will need a > lot of work? It shouldn't be any harder on 5.x / 6.x than on 7.x. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
