--- Ulf Lilleengen <lulf@stud.ntnu.no> wrote:
quoted text
> - 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...

quoted text
> - Proper indenting when breaking a line, should be 4 spaces etc.
>
Ohoh... I always tried to use tabs...

quoted text
> 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...

quoted text
> 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...

quoted text
> > 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...

quoted text
> 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...

quoted text
> 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)...

quoted text
> 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 
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"