--- Ulf Lilleengen <lulf_at_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.comReceived on Wed Nov 07 2007 - 21:23:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:21 UTC