Re: concurrent sysctl implementation
John, Thank you for your input on this matter, I'm excited to write some software for this project since its given me great code to learn from as i've grown up (still a kid though :). My questions are a bit more detailed below. On Mon, May 11, 2009 at 12:24 PM, John Baldwin j...@freebsd.org wrote: On Friday 08 May 2009 5:41:17 pm Ed Schouten wrote: A solution would be to solve it as follows: - Use a semaphore, initialized to some insane high value to put an upper limit on the amount of concurrent sysctl calls. I'm not sure whether this is really needed. Maybe this issue is not as serious as we think it is. Well, one compromise might be to allow concurrent userland requests if the buffer size is small (say 1 page). This would be a quite simple change and would cover many common syscalls like fetching an int which don't wire memory anyway. Why is this a compromise? Isn't concurrent sysctl calls from userland a good thing? What materials would be good to read other than the code and the sysctl manual pages? You said it would be relatively easy to implement this; what methods should I be considering to do this in and what part of the code specifically should I be looking at? - Use an rw/rm/sxlock to protect the sysctl tree, but only pick up the lock when we traverse parts of the sysctl tree that has dynamically created entries. I don't think further work is needed here for the tree, notice that in-kernel sysctls are already concurrent and use a read lock on the tree. yes i've seen the locking mechanism, it reminds me of a monitor type system... though from my understanding monitors appear seldom compared to semaphores in the kernel. I assume the lock will need a bit of twiddling with in some areas of the code if I'm going to enable concurrency from userland, when its said that we should consider the things that are dynamic would it be better to implement this with more than one queue or list? Instead perhaps break them up into several lists or, more fundamentally, two lists -- those that are dynamically created entries and those that are not -- is this even feasible to distinguish between the two originally and then on the fly later? Thanks a lot! Respectfully, /jt ___ 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: concurrent sysctl implementation
Ed, Thanks :) I'll be implementing this as discussed over the next few months thanks for the technical detail I've been extremely busy with finals. I will write the list with my thoughts within the next week, sorry for the delay. =jt On May 8, 2009, at 17:41, Ed Schouten e...@80386.nl wrote: Hi, * vasanth raonaik vasanth.raon...@gmail.com wrote: Hello Jt, I am a newbee in this alias. I am having a very basic question. It would be really good if you could give me some of this information. Could you please elaborate on what is the current architecture of sysctl implementation and How the concurrency would benefit us. Right now sysctl is synchronized using the sysctl lock. The problem is that certain sysctls just block for a very long time (especially some of the GEOM ones). We also call sysctl when we execute new processes, to obtain a random number for the stack protector. This means we have quite a lot of contention on it. This lock needs to be there, because sysctls can be added and removed on demand. I think I discussed this with John Baldwin (right?) and I think we also have the issue that we cannot allow an unbounded amount of concurrent calls to sysctl, because sysctl wires memory. A solution would be to solve it as follows: - Use a semaphore, initialized to some insane high value to put an upper limit on the amount of concurrent sysctl calls. I'm not sure whether this is really needed. Maybe this issue is not as serious as we think it is. - Use an rw/rm/sxlock to protect the sysctl tree, but only pick up the lock when we traverse parts of the sysctl tree that has dynamically created entries. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ ___ 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
concurrent sysctl implementation
Hackers, I've been using FreeBSD since a boy and now its time for me to give back. I will be doing my final projects in university concerning concurrency in the FreeBSD Kernel. I've been discussing with Ed@ methods of implementing sysctl concurrently since we use sysctl quite a lot for _everything_ essentially (make, general kernel information, etc). I've been reading the sysctl man pages and some of the code in the kernel; however, I wanted to shoot this out to the public since many of you know better than I do about where I should be looking to do the required reading to get the job done correctly. I'm also open to implementing other things once this is done. I hope everyone is doing well. respectfully, =jt ___ 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: keeping track of local modifications
On Tue, Dec 2, 2008 at 6:52 AM, Giorgos Keramidas [EMAIL PROTECTED] wrote: On Mon, 01 Dec 2008 21:08:25 -0800, [EMAIL PROTECTED] wrote: Git and Mercurial cannot import Subversion $FreeBSD$ lines so far, and you may end up submitting patches that include unexpanded forms of the $FreeBSD: $ text. These will fail to apply if they same patch touches nearby lines. Ahm, yes. sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g' should help in this case. You are right, of course. The fact that `$FreeBSD$' is extracted in unexpanded form by the current svn-hg converter is a limitation of the Python bindings of Subversion. They do not support expansion of the svn:keywords property of checked out files. good evening Giorgos and Eygene (and list), So am i to understand that there is no automatic way to use Hg or Git? -- and as Eygene said in order to use them in such a manner special patching will be required? I too am looking to set something else up other than my SVN repository because i personally prefer Hg and Git to SVN. Thank you to all who have contributed to this conversation it has been extremely informative for me and i'm sure several others. I hope everyone is looking forward to the holidays Respectfully, -- /jT http://git.zen-sources.org/?p=kernel/zenmm.git;a=summary ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel 5100 WiFi
Steve, A few Iwn drivers *are* supported, mine being iwn 4965 -- is supported and has been committed to 8.0-CURRENT. You can find more information about development on this hardware here : http://www.clearchain.com/blog/posts/iwn. I'm pretty sure that there is not that much work done on your model yet. Yes it will require a firmware blob as the 4965 one does. You are required to take notice to the legal aspects of the blob via setting a key in loader.conf. In terms of FreeBSD aligning with OpenBSD, I have no idea -- i have only run BSD. We *always* prefer Free as in Freedom -- hence FreeBSD -- again not sure what the OBSD policies are. In addition this is probably a better question for freebsd-mobile or freebsd-questions Thanks and good luck -- /jT http://git.zen-sources.org/?p=kernel/zenmm.git;a=summary ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel 5100 WiFi
Sam, I know you are busy, but can you explain what about my response was wrong when you say doesn't require sysctl ack -- you mean acknowledgment? I just would like to know for my future reference and Steve sorry for my misinformation. iwn firmware does not require a sysctl ack. Sam -- /jT http://git.zen-sources.org/?p=kernel/zenmm.git;a=summary ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: process hibernation and process descriptor table
Hello, This list is unrelated to linux, it was designed for technical discussion concerning the FreeBSD operating system: www.freebsd.org. If you are looking for linux help I recommend you check kernel.org for documentation and online forums. On 10/30/08, aniket pansare [EMAIL PROTECTED] wrote: hi guys i am doing a project on process hibernation. i am new to linux and i want u to tell me how can i print the contents of a process descriptor table. i had a look at the softwares like cryopid and BLCR but i am not able to get it at this stage. Any suggestions about how i should go about the project. Aniket Pansare ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- /jT http://git.zen-sources.org/?p=kernel/zenmm.git;a=summary ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 256-byte inode support
Kostik, Wesley,
I've been using this patch since Wesley made me aware of it -- it
has been 100% fine for me atm -- there are a few small modifications
to it and it applies cleanly to -CURRENT -- a bunch of my friends who
run all linux boxen (and i'm changing their minds about that slowly
but surely) use it and I have also _not_ heard a peep from them about
any failures / weirdness -- and most of their data exists on ext2fs :)
-- so thats a good sign -- i've attached the updated patch
--- ./ext2_fs.h.orig2008-09-13 23:25:32.0 +0100
+++ ./ext2_fs.h 2008-09-13 23:25:45.0 +0100
@@ -150,7 +150,7 @@
#else /* !notyet */
#defineEXT2_INODES_PER_BLOCK(s)((s)-s_inodes_per_block) /*
Should
be sizeof(struct ext2_inode): */
-#define EXT2_INODE_SIZE128
+#define EXT2_INODE_SIZE(s) ((s)-s_es-s_inode_size)
#define EXT2_FIRST_INO 11
#endif /* notyet */
--- ./ext2_inode.c.orig 2008-09-13 23:25:53.0 +0100
+++ ./ext2_inode.c 2008-09-13 23:26:06.0 +0100
@@ -91,7 +91,7 @@
return (error);
}
ext2_i2ei(ip, (struct ext2_inode *)((char *)bp-b_data +
- EXT2_INODE_SIZE * ino_to_fsbo(fs, ip-i_number)));
+ EXT2_INODE_SIZE(fs) * ino_to_fsbo(fs, ip-i_number)));
if (waitfor (vp-v_mount-mnt_kern_flag MNTK_ASYNC) == 0)
return (bwrite(bp));
else {
--- ./ext2_vfsops.c.orig2008-09-13 23:26:13.0 +0100
+++ ./ext2_vfsops.c 2008-09-13 23:26:55.0 +0100
@@ -424,7 +424,7 @@
V(s_frags_per_group)
fs-s_inodes_per_group = es-s_inodes_per_group;
V(s_inodes_per_group)
-fs-s_inodes_per_block = fs-s_blocksize / EXT2_INODE_SIZE;
+fs-s_inodes_per_block = fs-s_blocksize / EXT2_INODE_SIZE(fs);
V(s_inodes_per_block)
fs-s_itb_per_group = fs-s_inodes_per_group /fs-s_inodes_per_block;
V(s_itb_per_group)
@@ -578,7 +578,7 @@
return (error);
}
ext2_ei2i((struct ext2_inode *) ((char *)bp-b_data +
- EXT2_INODE_SIZE * ino_to_fsbo(fs, ip-i_number)), ip);
+ EXT2_INODE_SIZE(fs) * ino_to_fsbo(fs, ip-i_number)), ip);
brelse(bp);
VOP_UNLOCK(vp, 0);
vrele(vp);
@@ -1013,7 +1013,7 @@
return (error);
}
/* convert ext2 inode to dinode */
- ext2_ei2i((struct ext2_inode *) ((char *)bp-b_data + EXT2_INODE_SIZE *
+ ext2_ei2i((struct ext2_inode *) ((char *)bp-b_data +
EXT2_INODE_SIZE(fs) *
ino_to_fsbo(fs, ino)), ip);
ip-i_block_group = ino_to_cg(fs, ino);
ip-i_next_alloc_block = 0;
/jT
http://git.zen-sources.org/?p=kernel/zenmm.git;a=summary
On Tue, Sep 9, 2008 at 9:14 AM, Wesley Shields [EMAIL PROTECTED] wrote:
On Tue, Sep 09, 2008 at 03:37:47PM +0300, Kostik Belousov wrote:
On Tue, Sep 09, 2008 at 08:29:17AM -0400, Wesley Shields wrote:
On Tue, Sep 09, 2008 at 02:53:51PM +0300, Kostik Belousov wrote:
On Sun, Sep 07, 2008 at 11:07:47AM -0400, Wesley Shields wrote:
On Sat, Sep 06, 2008 at 07:26:27PM -0400, jT wrote:
hackers,
since tytso had updated ext3 -- i've noticed that i can't use my
265-byte inode ext3 drives -- is there any effort to update it? If
not -- if you know where i should attempt to start please let me know
so i can start working on support (i have a few other people i know
interested in this) -- thanks and hope everyone is well
There was a PR submitted for it and eventually a patch added to the PR.
I've tested the patch given in the URL at the port and it works. We
will start to see more of this as the newer version becomes more common
in the wild.
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124621
Would be nice to see this fixed in 7.1 but it may be too late for that.
What was the reason for increasing inode size ? I think it is rather
pointless to increase the size without using newly added space for some
data. Is inode format the same for the first 128 bytes, and does data
at the second 128 bytes should be used to correctly interpret inode ?
I honestly don't know the answer. Though I do agree that it is
pointless to increase the size without using the new space.
All I know is that I was unable to read an ext filesystem made with -I
256 (which is the default when using the most recent
sysutils/e2fsprogs).
I think it is too dangerous for the user data to commit this patch,
without investigating this first.
I think that's a fair assessment to make. The patch is certainly simple
enough but I'm not familiar with what it's doing to make an accurate
assessment. I know it worked for the simple test case I provided in my
previous message. If I can be of any further assistance please let me
know.
-- WXS
256-byte inode support
hackers, since tytso had updated ext3 -- i've noticed that i can't use my 265-byte inode ext3 drives -- is there any effort to update it? If not -- if you know where i should attempt to start please let me know so i can start working on support (i have a few other people i know interested in this) -- thanks and hope everyone is well respectfully, /jT ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Laptop suggestions?
of the projects sort of make people write code and drivers for the hardware that they have instead of just randomly supporting other machines -- subscribing to the acpi list might not be a bad idea -- i would poke them as well for a few hints if suspend is a huge deal for you -- hope this helps a bit respectfully -- jt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
