Date: Wed, 7 Nov 2007 14:16:20 -0800 (PST) From: Arne "Wörner" <arne_woerner@yahoo.com> To: Ulf Lilleengen <lulf@stud.ntnu.no>, Arne@stud.ntnu.no, W@stud.ntnu.no Cc: John Nielsen <john@jnielsen.net>, freebsd-current@freebsd.org, "fluffles.net" <bsd@fluffles.net> Subject: Re: geom_raid5 inclusion in HEAD? Message-ID: <613458.33465.qm@web30309.mail.mud.yahoo.com> In-Reply-To: <20071107210635.GA12736@stud.ntnu.no>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Ulf Lilleengen <lulf@stud.ntnu.no> wrote: > - Parantheses around return values: > Hmm... OK... I can do that, although "return" is no function... It feels more like an operator for me (like "=" or "++")... But if we want to do it that way, it is OK... > - Proper indenting when breaking a line, should be 4 spaces etc. > Ohoh... I always tried to use tabs... > All of this can be found in the style(9) manpage, so I'd rather just suggest > to go through it and make sure it's satisfied. > Hmm... Ooch... > I've only looked at TOS so far, but I'll look at PP as well to see how it is. > I have uploaded a PP version now, that has some explanations for each function or group of similar functions respectively... > > Hmm... if I understood correctly, FreeBSD's kernel memory suffers under > > fragmentation, if many big mem areas r needed... There might be even a dead > > lock, if UFS uses 64kb block size... So I thought it would be a good idea > to > > avoid those sleeps but "hamster-ing" the big chunks... :) But I am not sure > > anymore, that it improved performance (but performance was the reason for > > it)... > Hmm, I'm not sure what you mean about this dead lock, but sounds like a weird > thing to having to deadlock because of your filesystem. Maybe this could be > solved in another way, or is this not a graid5-thing at all? > It seems to be general problem with kernel and/or VFS memory... U can provoke it with heavy UFS access with several bonnie processes and UFS-block-size of 64kB... > The general thing is that I don't think one should start optimizing for > performance before everything works correctly and having made sure that it > improves performance statistically. (I know this isn't a completely new > project, but still). > Yup... And it's a little bit selfish to hamster memory... > First of all, disk I/O is generally much slower than CPU anyway, so I would > doubt that having to use one thread would decrease performance noticeably. > In my ears, this is a good argument for using one thread only. But then > again, this might not be a big deal if it's already there and it's correct. > Hmm... Yup... But reducing short delays (like for bcopy) increased throughput significantly (IIRC)... > I'm starting to get busier and busier with exams coming up now, but I'll try > take a look when I can, but don't expect to much :) Also, as I said, I've > only looked at TOS so far. > OK - I cannot spend so much time for this, too... I have a backlog of more than 10 hours of "important" TV series... :-) -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?613458.33465.qm>