sched_lock mutex and sleepq_wait
Hi,
I am trying to understand how msleep() routine suspends the currently
executing thread. I see that msleep() calls sleepq_wait().
What I don't understand here is the way in which sched_lock mutex is
handled.
I took the following snippet from FreeBSD 6:
sleepq_wait(void *wchan)
{
MPASS(!(curthread->td_flags & TDF_SINTR));
mtx_lock_spin(&sched_lock);
sleepq_switch(wchan);
mtx_unlock_spin(&sched_lock);
}
sched_lock mutex is held, and sleepq_switch() eventually calls
cpu_switch() which switches to a new thread.
I don't exactly understand when the sched_lock mutex is released.
Can someone please help me?
Thanks,
-shrivatsan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: "tar tfv /dev/cd0" speedup patch; Linux compatibility patches
Juergen Lock wrote: On Sun, Feb 21, 2010 at 05:17:37PM -0800, Tim Kientzle wrote: Could you try the current version of read_open_filename from: http://libarchive.googlecode.com/svn/trunk/libarchive/archive_read_open_filename.c Small but important bug: Index: archive_read_open_filename.c @@ -94,7 +94,7 @@ archive_read_open_filename(struct archiv struct read_file_data *mine; void *buffer; int fd; - int is_disk_like; + int is_disk_like = 0; Ah. Good catch! > Btw... the lseek + read combinations could also be replaced with pread(2), for the least amount of syscalls. :) Unfortunately, pread() isn't as portable. It's an interesting idea, though; maybe I'll play with that. (Especially since I noticed this version at least when ran on an optical disc with iso9660 ends up doing lots of lseek()s towards the end without ever reading anything from the disc anymore...) Fortunately, because there are no reads, those lseek() requests are pretty cheap. But you're right, it wouldn't be hard to eliminate the unnecessary system calls. Patches are here: (made on stable/8, if they don't apply on head I'll have to make extra versions for that...) http://people.freebsd.org/~nox/linuxdisk-blk.patch [1] http://people.freebsd.org/~nox/lseek-seek_end.patch [2] I'll let someone more familiar with the linuxolator code comment on those. And yes, with these patches the Linux bsdtar now also runs fast on FreeBSD. :) Excellent! Thanks so much for your help. If you have any further ideas (or patches ;-) for improving that libarchive code, please let me know. Cheers, Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: "tar tfv /dev/cd0" speedup patch; Linux compatibility patches
On Sun, Feb 21, 2010 at 05:17:37PM -0800, Tim Kientzle wrote: > Juergen, > > Could you try the current version of read_open_filename from: > > http://libarchive.googlecode.com/svn/trunk/libarchive/archive_read_open_filename.c > > You should be able to just copy it into your FreeBSD source > tree and recompile. > Small but important bug: Index: archive_read_open_filename.c @@ -94,7 +94,7 @@ archive_read_open_filename(struct archiv struct read_file_data *mine; void *buffer; int fd; - int is_disk_like; + int is_disk_like = 0; #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) off_t mediasize = 0; #elif defined(__NetBSD__) || defined(__OpenBSD__) > Duane Hesser's comments clarified for me that disk and tape > I/O do require fundamentally different strategies, so I > refactored this code to clearly break out those > strategies. This in turn allowed me to do some > straightforward I/O optimization of the disk case, > which sped up your example by about 100x. I have a 2G > DVD here on which "tar tvf /dev/acd0" took 90s originally, > takes 14s with your patch, and now takes only 0.6s. > For comparison, after mounting the disk, "find /mnt" > takes 1.6s (which drops to .1s after the cache is warmed). > It would be interesting to also compare two ways of > copying all of the files: "tar xvf /dev/acd0" > on an unmounted disk and "cp -R" on a mounted disk. > > The non-disk cases are all still handled generically, but > there are now clearly-labeled holes where someone could > add optimized I/O strategies for tapes, sockets, etc. > I've even included a number of TODO comments about > what strategies I think are worth exploring, including > tricks like using MTIO ioctls on tape, mmap() for disk, > and nonblocking I/O for sockets and pipes. I expect > any one of these is around a dozen lines of code, so > should be within the reach of even fairly junior > developers. Btw... the lseek + read combinations could also be replaced with pread(2), for the least amount of syscalls. :) (Especially since I noticed this version at least when ran on an optical disc with iso9660 ends up doing lots of lseek()s towards the end without ever reading anything from the disc anymore...) And to test the above fix, I ran the Linux-built bsdtar in the linuxolator, and after confirming it now does read all of the disc again I went and patched the remaining compatibility problems, i.e. I now have disks appear as block devices for Linux processes (there already was commented out code for that in linux_stats.c, I hope my version is now `correct enough' to be usable [1]), and I made a simple patch to make lseek SEEK_END (L_XTND in the source) dtrt on disk devices too by simply invoking the DIOCGMEDIASIZE ioctl there. [2] Patches are here: (made on stable/8, if they don't apply on head I'll have to make extra versions for that...) http://people.freebsd.org/~nox/linuxdisk-blk.patch [1] http://people.freebsd.org/~nox/lseek-seek_end.patch [2] And yes, with these patches the Linux bsdtar now also runs fast on FreeBSD. :) Cheers, Juergen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Anyone updating the Project Ideas page?
On Tue, Feb 23, 2010 at 1:00 AM, Aditya Sarawgi wrote: > On Mon, Feb 22, 2010 at 06:48:36AM -0800, Pedro F. Giffuni wrote: >> >> >> - Original Message >> ... >> > >> > On 7:49 19-02-10, Pedro F. Giffuni wrote: >> > > Hello; >> > > >> > > I've sent some private messages before trying to get >> > > some updates to the Project ideas page >> > > http://www.freebsd.org/projects/ideas/ideas.html >> > >> > >> > I'd like to see the whole thing moved to the wiki. >> > >> >> While I like the idea, as the website would be better >> maintained, I have to say in actual form the page >> looks better than in the wiki. >> >> >> Just my 0.02$, >> >> Pedro. >> > > +1 > With gsoc just around the corner I think the project ideas page should > be updated and moving the whole thing to wiki or maintaining a similar > page on wiki(along with the original page) sounds good to me. > I'll take the bait and make the page on the wiki. However someone else will have to update the doc source to include a link ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Anyone updating the Project Ideas page?
On Mon, Feb 22, 2010 at 06:48:36AM -0800, Pedro F. Giffuni wrote: > > > - Original Message > ... > > > > On 7:49 19-02-10, Pedro F. Giffuni wrote: > > > Hello; > > > > > > I've sent some private messages before trying to get > > > some updates to the Project ideas page > > > http://www.freebsd.org/projects/ideas/ideas.html > > > > > > I'd like to see the whole thing moved to the wiki. > > > > While I like the idea, as the website would be better > maintained, I have to say in actual form the page > looks better than in the wiki. > > > Just my 0.02$, > > Pedro. > +1 With gsoc just around the corner I think the project ideas page should be updated and moving the whole thing to wiki or maintaining a similar page on wiki(along with the original page) sounds good to me. > > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" -- Aditya Sarawgi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Anyone updating the Project Ideas page?
- Original Message ... > > On 7:49 19-02-10, Pedro F. Giffuni wrote: > > Hello; > > > > I've sent some private messages before trying to get > > some updates to the Project ideas page > > http://www.freebsd.org/projects/ideas/ideas.html > > > I'd like to see the whole thing moved to the wiki. > While I like the idea, as the website would be better maintained, I have to say in actual form the page looks better than in the wiki. Just my 0.02$, Pedro. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: ntpd hangs under FBSD 8
>You're going to need a debug version of libc, too. gdb won't be able to find >a backtrace out of a libc function without it. Yeah, you're right. This is definitely an annoying bug... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ntpd hangs under FBSD 8
You're going to need a debug version of libc, too. gdb won't be able to find a backtrace out of a libc function without it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: ntpd hangs under FBSD 8
>Just out of curiosity, can you attach to the process via gdb and get a >backtrace? This smells like a locked pthread_join I hit in my own code a few >weeks ago I'm not using the debug version of ntpd so the backtrace isn't too useful, but here's what I get: (gdb) bt #0 0x000800d52bfc in select () from /lib/libc.so.7 #1 0x00425273 in ?? () #2 0x0040540e in ?? () #3 0x00080058 in ?? () #4 0x in ?? () The trace continues for 700+ entries. The first entry is useful enough though. One of the parameters to select() is a timeout parameter. Every time I do the backtrace it's stuck on this select call so it seems they have an infinite timeout set. One of these was running all weekend in fact and it's still stuck. Curiously, this problem only happens when we make the call from code via a system() call. If I run the same command interactively, it never hangs: # /usr/sbin/ntpd -g -q ntpd: time set +28845.997063s The same code that runs this command does not hang when we run it on a BSD 7 box. I think I'm going to have to build the debug version of ntpd and try to debug it. Definitely something weird going on. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Anyone updating the Project Ideas page?
On 7:49 19-02-10, Pedro F. Giffuni wrote: > Hello; > > I've sent some private messages before trying to get > some updates to the Project ideas page > http://www.freebsd.org/projects/ideas/ideas.html I'd like to see the whole thing moved to the wiki. -- Joel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: `make cleanworld` and /usr/obj/lib32/usr/src
On Mon, 22 Feb 2010 00:20:14 +0100 (CET) Alexander Best wrote: > hi there, > > anybody fancy the idea of including /usr/obj/lib32/usr/src in the cleanworld > target on amd64? > Seems like a reasonable thing to do. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
