Re: GSoC: Avoiding syscall overhead
On Tue, Apr 5, 2011 at 7:00 PM, Israel Jacques wrote: > I'll be looking to go through: > src/sys/vm > src/lib/libc/gen/setproctitle.c > src/sys/kern/sysv_shm.c > ...and the VM portion of the "4.4BSD" book. > (I just received my FreeBSD book today!) You may also want to take a look at "Solaris Internals" book. It may give you some food for thought. ISBN: 9780131482098 --Artem ___ 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: GSoC: Avoiding syscall overhead
On Tue, Apr 5, 2011 at 19:43, Artem Belevich wrote: > On Tue, Apr 5, 2011 at 7:00 PM, Israel Jacques wrote: >> I'll be looking to go through: >> src/sys/vm >> src/lib/libc/gen/setproctitle.c >> src/sys/kern/sysv_shm.c >> ...and the VM portion of the "4.4BSD" book. >> (I just received my FreeBSD book today!) > > You may also want to take a look at "Solaris Internals" book. It may > give you some food for thought. > ISBN: 9780131482098 Thank you. Will do. > --Artem > ___ 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"
GSoC: Avoiding syscall overhead
Hello, I have sent a copy to one of the people listed as technical support (atillio@). My name is Israel Jacques and I'm an undergrad at the University of California, Berkeley. I am interested in working on removing overhead from the 'SETPROCTITLE(3)' library routine. I see that in the ideas page work has already begun to make this optimization. However, searching through the mailing lists I have not found much discussion on it. After looking through the archives (see references), I have some (crude) high level ideas as to how to approach the problem. The idea, as suggested is to have a shared page between the kernel and a userland process. Having such a shared page would avoid having to invoke sysctl() which causes a the large overhead of a context switch. The shared page 1. needs to be pinned as to avoid having it be paged out. 2. needs to stay alive for the entire duration of the process. 3. needs to be unique for every process. Initially, I was thinking that a shared page should be created for ALL processes, but that would expose vital information to all other processes. Furthermore, any other process can alter the information of another process. As suggested in [9], allocating memory and reserving some region of the process address space, pinning it, and setting the correct page permissions (permissions in the PTE?) would be enough to create such a shared page. Though, letting the process know of this page would require a system call. Again, suggested in reference [9] would add a section in the ELF which would then have a global variable of (potentially) a pointer to a struct with the process information. Of course, a process could mistakenly use the pointer to access outside the bounds of the page and cause trouble. Furthermore, checks need to be made to insure that the process itself doesn't corrupt the information in the struct. Also, for every access a mutex would be needed as to avoid possible race conditions between both the kernel and the process. I'll be looking to go through: src/sys/vm src/lib/libc/gen/setproctitle.c src/sys/kern/sysv_shm.c ...and the VM portion of the "4.4BSD" book. (I just received my FreeBSD book today!) References: [1] http://lists.freebsd.org/pipermail/freebsd-hackers/2009-October/029750.html [2] http://lists.freebsd.org/pipermail/freebsd-performance/2006-June/002038.html [3] http://lists.freebsd.org/pipermail/freebsd-stable/2006-October/029983.html [4] http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039392.html [5] http://lists.freebsd.org/pipermail/freebsd-performance/2008-January/003107.html [6] http://lists.freebsd.org/pipermail/freebsd-hackers/2008-March/023875.html [7] http://lists.freebsd.org/pipermail/freebsd-hackers/2005-November/014452.html [8] http://lists.freebsd.org/pipermail/freebsd-hackers/2011-February/034419.html [9] http://lists.freebsd.org/pipermail/freebsd-hackers/2005-November/014453.html ___ 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: Updating PCI vendors database
On Mon, Apr 04, 2011 at 08:30:38PM -0700, Garrett Cooper wrote: > On Mon, Apr 4, 2011 at 11:04 AM, Doug Barton wrote: > > On 04/04/2011 07:10, Philip Paeps wrote: > >> > >> It looks like our /usr/share/misc/pci_vendors list (used only by pciconf > >> as > >> far as I can tell) has become rather stale. ?We also appear to be tracking > >> sources which no longer exist. > >> > >> Would anyone object if I updated this list to source the same database > >> used by > >> Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids? > >> > >> It helps that our pciconf looks to be compatible with that format. ?We > >> just > >> ignore subvendor and subdevice, but it doesn't appear to matter that the > >> file > >> contains this information. > >> > >> I could cull the subvendor/subdevice from the list though. > >> > >> Any views? > > > > Having read this thread, and the last one, my opinion is, let's do it > > already. :) ?Repo churn should not, under any circumstances, be a > > consideration in technical improvements. I agree with those who have said > > that the new list should be confirmed to be a superset of the old, and > > anything missing should be merged in. Checking with Jack about Intel stuff > > is also reasonable, as would be cross-checking with what NetBSD and OpenBSD > > are doing (and perhaps communicating with them about your work). > > 1. People may have automation that depends on this output. This was my only concern about churn in the previous conversation. Given that the lists were using are defunct, we should just move to pci.ids unless someone verifies that a signficant number of devices are missing. If that were to happen I'd just add a local source file to merge into pci.ids and let pci.ids be the master. -- Brooks pgp76MOeGNIEh.pgp Description: PGP signature
Re: [gsoc] HTree Directory Index and Journal in ext2fs
2011/4/5 Ivan Voras > On 05/04/2011 15:48, gnehzuil wrote: > >> Hello, >> >> I would like to apply a new project "HTree Directory Index and Journal >> in ext2fs" in GSoC 2011. This project is not in ideas page. But this >> project can improve ext2fs in FreeBSD. >> >> Last year, I have participated GSoC 2010 and have implemented a >> preallocation algorithm in ext2fs and make it can read ext4 file system >> in read-only mode. I have try to read htree dir index in ext4 read-only >> mode. Yet I don't finish it. I am plan to implement a htree dir index in >> ext2fs before midterm evaluation. >> >> Next I will try to implement journal in ext2fs. I think I can borrow >> some ideas from WAPBL in NetBSD. >> > > When you say 'journal in ext2fs' do you mean ext3-compatible or something > different entirely? I don't think that a journalling addition to our ext2fs > which would not make it compatible with ext3 would be useful. > IMHO, I want to add a ext3-compatible journal. In previously discussion, Pedro and I have mentioned WAPBL and its performance is awesome. So I want to look at it and maybe I can borrow some good ideas. > > > ___ > 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" > -- Liu Zheng gnehz...@gmail.com CNU NetLab Tsinghua CSCW ___ 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: [gsoc] HTree Directory Index and Journal in ext2fs
On 05/04/2011 15:48, gnehzuil wrote: Hello, I would like to apply a new project "HTree Directory Index and Journal in ext2fs" in GSoC 2011. This project is not in ideas page. But this project can improve ext2fs in FreeBSD. Last year, I have participated GSoC 2010 and have implemented a preallocation algorithm in ext2fs and make it can read ext4 file system in read-only mode. I have try to read htree dir index in ext4 read-only mode. Yet I don't finish it. I am plan to implement a htree dir index in ext2fs before midterm evaluation. Next I will try to implement journal in ext2fs. I think I can borrow some ideas from WAPBL in NetBSD. When you say 'journal in ext2fs' do you mean ext3-compatible or something different entirely? I don't think that a journalling addition to our ext2fs which would not make it compatible with ext3 would be useful. ___ 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"
[gsoc] HTree Directory Index and Journal in ext2fs
Hello, I would like to apply a new project "HTree Directory Index and Journal in ext2fs" in GSoC 2011. This project is not in ideas page. But this project can improve ext2fs in FreeBSD. Last year, I have participated GSoC 2010 and have implemented a preallocation algorithm in ext2fs and make it can read ext4 file system in read-only mode. I have try to read htree dir index in ext4 read-only mode. Yet I don't finish it. I am plan to implement a htree dir index in ext2fs before midterm evaluation. Next I will try to implement journal in ext2fs. I think I can borrow some ideas from WAPBL in NetBSD. Best regards, lz ___ 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: looking for error codes
on 01/04/2011 17:29 Andriy Gapon said the following: > > I am looking for error codes that would unambiguously signal that a disk > drive has > readonly or write-protected media and that disk drive has no media at the > moment. > I foresee these error codes being used mostly between disk peripheral drivers > and > filesystem drivers. > > I will appreciate your suggestions. > > P.S. > I see that Linux uses EROFS and ENOMEDIUM for these purposes. > I am not sure about EROFS in this role. > And we don't have ENOMEDIUM (nor EMEDIUMTYPE). Thanks for all the error code suggestions so far :-) It seems that ENODEV could be a good choice for signaling readonly or write-protected media on write access: 19 ENODEV Operation not supported by device. An attempt was made to apply an inappropriate function to a device, for example, trying to read a write-only device such as a printer. BTW, SCSI code currently maps that condition to EACCES, but I don't think that that is the best choice - the error could be also produced by "permissions-related" checks. E.g. from intro(2): 13 EACCES Permission denied. An attempt was made to access a file in a way forbidden by its file access permissions. As for the ENOMEDIUM, I don't think that adding a distinct error code here would provide any new useful abilities. So, ENXIO should still be a good option. -- Andriy Gapon ___ 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"
