Skip site navigation (1)Skip section navigation (2)
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>