Nabble - freebsd-arch

Re: network statistics in SMP

2009-12-16T10:19:45Z

On Tue, 15 Dec 2009, John Baldwin wrote:

> On Tuesday 15 December 2009 12:45:13 pm Harti Brandt wrote:
>> On Tue, 15 Dec 2009, John Baldwin wrote:
>>
>> JB>On Tuesday 15 December 2009 4:38:04 am Harti Brandt wrote:
>> JB>> Hi all,
>> JB>>
>> JB>> I'm working on our network statistics (in the context of SNMP) and wonder,
>> JB>> to what extend we want them to be correct. I've re-read part of the past
>> JB>> discussions about 64-bit counters on 32-bit archs and got the impression,
>> JB>> that there are users that would like to have almost correct statistics
>> JB>> (for accounting, for example). If this is the case I wonder whether the
>> JB>> way we do the statistics today is correct.
>> JB>>
>> JB>> Basically all statistics are incremented or added to simply by a += b oder
>> JB>> a++. As I understand, this worked fine in the old days, where you had
>> JB>> spl*() calls at the right places. Nowadays when everything is SMP
>> JB>> shouldn't we use at least atomic operations for this? Also I read that on
>> JB>> architectures where cache coherency is not implemented in hardware even
>> JB>> this does not help (I found a mail from jhb why for the mutex
>> JB>> implementation this is not a problem, but I don't understand what to do
>> JB>> for the += and ++ operations). I failed to find a way, though, to
>> JB>> influence the caching policy (is there a function one can call to
>> JB>> change the policy?).
>> JB>
>> JB>Atomic ops will always work for reliable statistics. However, I believe
>> JB>Robert is working on using per-CPU statistics for TCP, UDP, etc. similar to
>> JB>what we do now for many of the 'cnt' stats (context switches, etc.). For
>> JB>'cnt' each CPU has its own count of stats that are updated using non-atomic
>> JB>ops (since they are CPU local). sysctl handlers then sum up the various per-
>> JB>CPU counts to report global counts to userland.

I don't like the bloat from this, but don't see anything better. Julian
said in another reply that there are even more complications for VIMAGE.

>> I see. I was also thinking along these lines, but was not sure whether it
>> is worth the trouble. I suppose this does not help to implement 64-bit
>> counters on 32-bit architectures, though, because you cannot read them
>> reliably without locking to sum them up, right?
>
> Either that or you just accept that you have a small race since it is only stats. :)

Actually, you can do better with a generation count. The generation count
would at least tell you if you lost a race. The generation count should
only be maintained while summing other counts, since it must be global and
incremented by atomic ops (to avoid the races without even more costly
locking which would make the generation count irrelevant) so maintaining
it all the time would more than defeat the point of having per-CPU counters
(all CPUs would compete for it at the same address). Probably not worth
it for statistics. Except, if userland had control over it, then userland
could decide the policy.

Actually2, this solves your original problem!, provided the races are
so rarely lost that looping to recover from them works: Once counters
are per-CPU, they can be 64-bits with no complications until they are
summed. Detection of lost races is essential for summing them on
32-bit systems, unlike for 32-bit counters, since a lost race at the
point where the low 32 bits wraps around may give an error of 2**32
in the sum, while a lost race for a 32-bit counter only makes the sum
a bit too small (unless the 32-bit counter wrapped).

Simple version:
- bloat PCPU_INC(var) to do something like the following:
if (PCPU_GET(counter_summing_mode))
atomic_add_int(&counter_gen, 1);
OLD_PCPU_INC(var);
- set PCPU_GET(counter_summing_mode) while summing. Needs heavyweight
synchronization (IPIs?) to set and clear the flag on other CPUs. Must
also make all other CPUs flush pending writes (so that a 64-bit counter
cannot be half-written at the beginning of the summing), but this will
happen automatically with any heavyweight synchronization.

Unsimple versions: to avoid bloating PCPU_INC(), write-protect all
counters while summing, and count generations in the trap handler ...

However, I prefer summing 32-bit counters (with heuristics to detect
wraparound) to a 64-bit sum, like I think you already do for SNMP.

Wraparound heuristics may still be useful with the generation count:
suppose the generation count increases faster than you can sum; then
looping to get a coherent sum doesn't work, and wraparound must be
ruled out or fixed up in another way; the 32-bit wraparound heuristic
works perfectly since we can guarantee to sum faster than a 32-bit
counter can wrap twice.

Bruce
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: network statistics in SMP

2009-12-15T10:13:28Z

On Tuesday 15 December 2009 12:45:13 pm Harti Brandt wrote:

> On Tue, 15 Dec 2009, John Baldwin wrote:
>
> JB>On Tuesday 15 December 2009 4:38:04 am Harti Brandt wrote:
> JB>> Hi all,
> JB>>
> JB>> I'm working on our network statistics (in the context of SNMP) and wonder,
> JB>> to what extend we want them to be correct. I've re-read part of the past
> JB>> discussions about 64-bit counters on 32-bit archs and got the impression,
> JB>> that there are users that would like to have almost correct statistics
> JB>> (for accounting, for example). If this is the case I wonder whether the
> JB>> way we do the statistics today is correct.
> JB>>
> JB>> Basically all statistics are incremented or added to simply by a += b oder
> JB>> a++. As I understand, this worked fine in the old days, where you had
> JB>> spl*() calls at the right places. Nowadays when everything is SMP
> JB>> shouldn't we use at least atomic operations for this? Also I read that on
> JB>> architectures where cache coherency is not implemented in hardware even
> JB>> this does not help (I found a mail from jhb why for the mutex
> JB>> implementation this is not a problem, but I don't understand what to do
> JB>> for the += and ++ operations). I failed to find a way, though, to
> JB>> influence the caching policy (is there a function one can call to
> JB>> change the policy?).
> JB>
> JB>Atomic ops will always work for reliable statistics. However, I believe
> JB>Robert is working on using per-CPU statistics for TCP, UDP, etc. similar to
> JB>what we do now for many of the 'cnt' stats (context switches, etc.). For
> JB>'cnt' each CPU has its own count of stats that are updated using non-atomic
> JB>ops (since they are CPU local). sysctl handlers then sum up the various per-
> JB>CPU counts to report global counts to userland.
>
> I see. I was also thinking along these lines, but was not sure whether it
> is worth the trouble. I suppose this does not help to implement 64-bit
> counters on 32-bit architectures, though, because you cannot read them
> reliably without locking to sum them up, right?

Either that or you just accept that you have a small race since it is only stats. :)

--
John Baldwin
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: network statistics in SMP

2009-12-15T09:45:13Z

On Tue, 15 Dec 2009, John Baldwin wrote:

JB>On Tuesday 15 December 2009 4:38:04 am Harti Brandt wrote:
JB>> Hi all,
JB>>
JB>> I'm working on our network statistics (in the context of SNMP) and wonder,
JB>> to what extend we want them to be correct. I've re-read part of the past
JB>> discussions about 64-bit counters on 32-bit archs and got the impression,
JB>> that there are users that would like to have almost correct statistics
JB>> (for accounting, for example). If this is the case I wonder whether the
JB>> way we do the statistics today is correct.
JB>>
JB>> Basically all statistics are incremented or added to simply by a += b oder
JB>> a++. As I understand, this worked fine in the old days, where you had
JB>> spl*() calls at the right places. Nowadays when everything is SMP
JB>> shouldn't we use at least atomic operations for this? Also I read that on
JB>> architectures where cache coherency is not implemented in hardware even
JB>> this does not help (I found a mail from jhb why for the mutex
JB>> implementation this is not a problem, but I don't understand what to do
JB>> for the += and ++ operations). I failed to find a way, though, to
JB>> influence the caching policy (is there a function one can call to
JB>> change the policy?).
JB>
JB>Atomic ops will always work for reliable statistics. However, I believe
JB>Robert is working on using per-CPU statistics for TCP, UDP, etc. similar to
JB>what we do now for many of the 'cnt' stats (context switches, etc.). For
JB>'cnt' each CPU has its own count of stats that are updated using non-atomic
JB>ops (since they are CPU local). sysctl handlers then sum up the various per-
JB>CPU counts to report global counts to userland.

I see. I was also thinking along these lines, but was not sure whether it
is worth the trouble. I suppose this does not help to implement 64-bit
counters on 32-bit architectures, though, because you cannot read them
reliably without locking to sum them up, right?

harti
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: network statistics in SMP

2009-12-15T09:08:09Z

John Baldwin wrote:

> On Tuesday 15 December 2009 4:38:04 am Harti Brandt wrote:
>> Hi all,
>>
>> I'm working on our network statistics (in the context of SNMP) and wonder,
>> to what extend we want them to be correct. I've re-read part of the past
>> discussions about 64-bit counters on 32-bit archs and got the impression,
>> that there are users that would like to have almost correct statistics
>> (for accounting, for example). If this is the case I wonder whether the
>> way we do the statistics today is correct.
>>
>> Basically all statistics are incremented or added to simply by a += b oder
>> a++. As I understand, this worked fine in the old days, where you had
>> spl*() calls at the right places. Nowadays when everything is SMP
>> shouldn't we use at least atomic operations for this? Also I read that on
>> architectures where cache coherency is not implemented in hardware even
>> this does not help (I found a mail from jhb why for the mutex
>> implementation this is not a problem, but I don't understand what to do
>> for the += and ++ operations). I failed to find a way, though, to
>> influence the caching policy (is there a function one can call to
>> change the policy?).
>
> Atomic ops will always work for reliable statistics. However, I believe
> Robert is working on using per-CPU statistics for TCP, UDP, etc. similar to
> what we do now for many of the 'cnt' stats (context switches, etc.). For
> 'cnt' each CPU has its own count of stats that are updated using non-atomic
> ops (since they are CPU local). sysctl handlers then sum up the various per-
> CPU counts to report global counts to userland.

the trouble is that PCPU and VNET collide. you then need to have
Per-CPU, per VNET counters. which would be yet a different pool of
linker set symbols..

>

_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: network statistics in SMP

2009-12-15T05:12:35Z

On Tuesday 15 December 2009 4:38:04 am Harti Brandt wrote:

> Hi all,
>
> I'm working on our network statistics (in the context of SNMP) and wonder,
> to what extend we want them to be correct. I've re-read part of the past
> discussions about 64-bit counters on 32-bit archs and got the impression,
> that there are users that would like to have almost correct statistics
> (for accounting, for example). If this is the case I wonder whether the
> way we do the statistics today is correct.
>
> Basically all statistics are incremented or added to simply by a += b oder
> a++. As I understand, this worked fine in the old days, where you had
> spl*() calls at the right places. Nowadays when everything is SMP
> shouldn't we use at least atomic operations for this? Also I read that on
> architectures where cache coherency is not implemented in hardware even
> this does not help (I found a mail from jhb why for the mutex
> implementation this is not a problem, but I don't understand what to do
> for the += and ++ operations). I failed to find a way, though, to
> influence the caching policy (is there a function one can call to
> change the policy?).

Atomic ops will always work for reliable statistics. However, I believe
Robert is working on using per-CPU statistics for TCP, UDP, etc. similar to
what we do now for many of the 'cnt' stats (context switches, etc.). For
'cnt' each CPU has its own count of stats that are updated using non-atomic
ops (since they are CPU local). sysctl handlers then sum up the various per-
CPU counts to report global counts to userland.

--
John Baldwin
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

network statistics in SMP

2009-12-15T01:38:04Z

Hi all,

I'm working on our network statistics (in the context of SNMP) and wonder,
to what extend we want them to be correct. I've re-read part of the past
discussions about 64-bit counters on 32-bit archs and got the impression,
that there are users that would like to have almost correct statistics
(for accounting, for example). If this is the case I wonder whether the
way we do the statistics today is correct.

Basically all statistics are incremented or added to simply by a += b oder
a++. As I understand, this worked fine in the old days, where you had
spl*() calls at the right places. Nowadays when everything is SMP
shouldn't we use at least atomic operations for this? Also I read that on
architectures where cache coherency is not implemented in hardware even
this does not help (I found a mail from jhb why for the mutex
implementation this is not a problem, but I don't understand what to do
for the += and ++ operations). I failed to find a way, though, to
influence the caching policy (is there a function one can call to
change the policy?).

Any opinions?
harti
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: src/Makefile, universe, LINT, VIMAGE, ..

2009-12-14T13:01:41Z

On Mon, 14 Dec 2009, John Baldwin wrote:

> I think you can drop the 'KERNCONFS:= ${KERNCONFS}' line now.

So I did; thanks.

>>>>> Index: sys/conf/makeLINT.mk
>>>>> ===================================================================
>>>>> --- sys/conf/makeLINT.mk (revision 198467)
>>>>> +++ sys/conf/makeLINT.mk (working copy)
>>>>> @@ -5,7 +5,15 @@
>>>>>
>>>>> clean:
>>>>> rm -f LINT
>>>>> +.if ${TARGET} == "amd64" || ${TARGET} == "i386"
>>>>> + rm -f LINT=VIMAGE
>>>>> +.endif
>>>>
>>>> s/=/-/
>>>
>>> Yeah, everyone notics that one; it should be fixed in the patch at the
>>> URL originally referenced.
>
> This is still here. :)

*grump* I had fixed it in the patch but not in my working tree.

New try:
http://people.freebsd.org/~bz/20091214-01-make-LINT-VIMAGE.diff

--
Bjoern A. Zeeb It will not break if you know what you are doing.
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: src/Makefile, universe, LINT, VIMAGE, ..

2009-12-14T08:19:36Z

On Sunday 13 December 2009 2:55:58 pm Bjoern A. Zeeb wrote:
> >> Also, I would probably prefer to have
> >> universe_kernels come after universe_$target and before
universe_epilogue.
> >
> > I think that should be possible to sneak it in after the the .endfor.
>
> I fixed those; I needed to allow the target for the outer .if make()
> though with that.

I think you can drop the 'KERNCONFS:= ${KERNCONFS}' line now.

> >>> Index: sys/conf/makeLINT.mk
> >>> ===================================================================
> >>> --- sys/conf/makeLINT.mk (revision 198467)
> >>> +++ sys/conf/makeLINT.mk (working copy)
> >>> @@ -5,7 +5,15 @@
> >>>
> >>> clean:
> >>> rm -f LINT
> >>> +.if ${TARGET} == "amd64" || ${TARGET} == "i386"
> >>> + rm -f LINT=VIMAGE
> >>> +.endif
> >>
> >> s/=/-/
> >
> > Yeah, everyone notics that one; it should be fixed in the patch at the
> > URL originally referenced.

This is still here. :)

--
John Baldwin
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Current problem reports assigned to freebsd-arch@FreeBSD.org

2009-12-14T03:06:50Z

Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker Resp. Description
--------------------------------------------------------------------------------
o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache

1 problem total.

_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: src/Makefile, universe, LINT, VIMAGE, ..

2009-12-13T11:55:58Z

On Mon, 26 Oct 2009, Bjoern A. Zeeb wrote:

Hi,

> On Mon, 26 Oct 2009, John Baldwin wrote:
>
> Hi,
>
>>> @@ -345,3 +333,18 @@
>>> fi
>>> .endif
>>> .endif
>>> +
>>> +universe_kernels: universe_kernels_foo
>>> +TARGET?= ${BUILD_ARCH}
>>> +KERNCONFS!= cd ${.CURDIR}/sys/${TARGET}/conf && \
>>> + find [A-Z0-9]*[A-Z0-9] -type f -maxdepth 0 \
>>> + ! -name DEFAULTS ! -name NOTES
>>> +KERNCONFS:= ${KERNCONFS}
>>> +universe_kernels_foo:
>>> +.for kernel in ${KERNCONFS}
>>> + @(cd ${.CURDIR} && env __MAKE_CONF=/dev/null \
>>> + ${MAKE} ${JFLAG} buildkernel TARGET=${TARGET} KERNCONF=${kernel}
>>> \
>>> + > _.${TARGET}.${kernel} 2>&1 || \
>>> + (echo "${TARGET} ${kernel} kernel failed," \
>>> + "check _.${TARGET}.${kernel} for details"| ${MAKEFAIL}))
>>> +.endfor
>>
>> Hmm, I'm not sure why you need a universe_kernels_foo target that
>> universe_kernels depends on?
>
> This is all about make and the variables after a target and within a
> target. Whatever else I tried: make complained. If you know the
> rightbetter solution that works I'll be happy to simplify this and
> update the patch.
>
> It shouldn't be named _foo though;)
>
>
>> Also, I would probably prefer to have
>> universe_kernels come after universe_$target and before universe_epilogue.
>
> I think that should be possible to sneak it in after the the .endfor.

I fixed those; I needed to allow the target for the outer .if make()
though with that.

>>> Index: sys/conf/makeLINT.mk
>>> ===================================================================
>>> --- sys/conf/makeLINT.mk (revision 198467)
>>> +++ sys/conf/makeLINT.mk (working copy)
>>> @@ -5,7 +5,15 @@
>>>
>>> clean:
>>> rm -f LINT
>>> +.if ${TARGET} == "amd64" || ${TARGET} == "i386"
>>> + rm -f LINT=VIMAGE
>>> +.endif
>>
>> s/=/-/
>
> Yeah, everyone notics that one; it should be fixed in the patch at the
> URL originally referenced.
>
>> BTW, I'm not sure why you would only enable VIMAGE for these two archs
>> rather
>> than doing it for all archs that have a LINT?
>
> Because it'll usually simply not make any sense to build a VIMAGE
> kernel for embedded platforms like arm, ... Also make universe time
> increases significantly with any platform; indeed amd64 is the worst
> now (again). We can talk about the proper set and I had thought of
> sparc64 as well. Obviously just building it everywhere simplifies
> things.

An updated patch to test would be here:
http://people.freebsd.org/~bz/20091213-01-make-LINT-VIMAGE.diff

/bz

--
Bjoern A. Zeeb It will not break if you know what you are doing.
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: Testing CAM wrapper for ata(4) controller drivers

2009-12-10T06:31:41Z

On Dec 10, 2009, at 3:02 AM, Alexander Motin wrote:

> Alexander Motin wrote:
>> The main regression of the new mode is a lack of ataraid
>> alternative, to
>> support cheap BIOS-based ATA RAIDs. If somebody has time and wish to
>> port that code from inside ata(4) into GEOM module, to make it work
>> over
>> CAM also, I would appreciate that and propose a help, if needed.
>
> May be it would be easier to just teach gmirror, gstripe and gconcat
> to
> handle ATA RAIDs metadata formats, to not duplicate and support the
> rest
> of code.
>

The existing graid modules are not well suited for learning new
metadata. I have plans for restructuring them into a stack within
GEOM that handles metadata separate from the transforms.

Scott

_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: Testing CAM wrapper for ata(4) controller drivers

2009-12-10T02:02:08Z

Alexander Motin wrote:
> The main regression of the new mode is a lack of ataraid alternative, to
> support cheap BIOS-based ATA RAIDs. If somebody has time and wish to
> port that code from inside ata(4) into GEOM module, to make it work over
> CAM also, I would appreciate that and propose a help, if needed.

May be it would be easier to just teach gmirror, gstripe and gconcat to
handle ATA RAIDs metadata formats, to not duplicate and support the rest
of code.

--
Alexander Motin
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: Inquiry about the 7.2 release CD/DVD

2009-12-09T11:45:57Z

Doug Barton wrote:

> Julian H. Stacey wrote:
> > Roger Agraviador wrote:
> >> Hi!
> >> I am quite new to BSD (Open source OS'es in general)
> >
> > This arch@ list is for complex advanced questions, so please send
> > future simple beginner questions to questions@....
>
> A more friendly way to say that would be, "If you're not sure where to
> send a question about FreeBSD freebsd-questions@... is always
> a safe bet." :)
>
> We were all beginners once, and we like to encourage them as much as
> possible.

Doug did not answer Roger. I took time so Roger would get an answer,
while saving time of specialists on @arch who didn't need to lose
time answering simple questions. Criticism off list please.

Cheers,
Julian
--
Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
Mail plain text not quoted-printable, HTML or Base64: http://asciiribbon.org
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: Inquiry about the 7.2 release CD/DVD

2009-12-08T17:00:03Z

Julian H. Stacey wrote:
> Roger Agraviador wrote:
>> Hi!
>> I am quite new to BSD (Open source OS'es in general)
>
> This arch@ list is for complex advanced questions, so please send
> future simple beginner questions to questions@....

A more friendly way to say that would be, "If you're not sure where to
send a question about FreeBSD freebsd-questions@... is always
a safe bet." :)

We were all beginners once, and we like to encourage them as much as
possible.

Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: Inquiry about the 7.2 release CD/DVD

2009-12-08T14:57:55Z

Roger Agraviador wrote:
> Hi!
> I am quite new to BSD (Open source OS'es in general)

This arch@ list is for complex advanced questions, so please send
future simple beginner questions to questions@....

> and would like to
> try the 7.2 release,

8.0 is out now too, if you'r feeling adventurous.

> If I where to purchase a copy would it be
> possible to use it in several computers with different processors?

The DVDs that freebsd.org offer free for download are for one CPU only.
(though both i386 & amd64 DVDs & CDs will run on amd64 CPU).

> Since I am planning to make a computer with an AMD Athlon II 64, and
> If I am happy with it, i'd like to share it with my relatives and
> friends if that is possible or would sharing violate any legal rights
> and licenses?

FreeBSD would like you to give FreeBSD free to lots of people :-)

You can download the generic FreeBSD DVDs, burn them, copy them,
sell them even. Read the 6K Coyright in /usr/src/COPYRIGHT
which one might summarise crudely as:
"Do what you want, but don't blame us" :-)

http://www.freebsd.org also lists some commercial vendors of DVDs,
If you choose to buy those discs rather than download & burn the
free ones direct from http://www.freebsd.orgm then an additional
agregation copyright may apply from the agregator firm, in which
case for those, you may not be entitled to make copies of the DVD
image, but are entitled to make unlimited copies of source code
from FreeBSD.

The individual extra 20,918 ported packages have a myriad
of different licences, depending which ones you want to add.

Please read http://www.freebsd.org & use questions@...

Cheers,
Julian
--
Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
Mail plain text not quoted-printable, HTML or Base64: http://asciiribbon.org
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: Inquiry about the 7.2 release CD/DVD

2009-12-08T14:43:14Z

Roger Agraviador wrote:
> Hi!
>
> I am quite new to BSD (Open source OS'es in general) and would like to
> try the 7.2 release, If I where to purchase a copy would it be possible
> to use it in several computers with different processors? Since I am
> planning to make a computer with an AMD Athlon II 64, and If I am happy
> with it, i'd like to share it with my relatives and friends if that is
> possible or would sharing violate any legal rights and licenses?

All FreeBSD releases are freely available for download as ISO images.
You can download them, burn them and share them with anybody you want.
The only thing you need to be aware of is the processor type. If you
what to run 32bit OS, you need i386 ISO image / CD. If you want 64bit
OS, you need amd64 ISO / CD.
(there are images for alpha, ia64, pc98, powerpc and sparc64 too)
ftp://ftp.freebsd.org/pub/FreeBSD/

FreeBSD is made under BSD license:
http://www.freebsd.org/copyright/freebsd-license.html

Miroslav Lachman
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Inquiry about the 7.2 release CD/DVD

2009-12-08T13:40:03Z

Hi!

I am quite new to BSD (Open source OS'es in general) and would like to
try the 7.2 release, If I where to purchase a copy would it be
possible to use it in several computers with different processors?
Since I am planning to make a computer with an AMD Athlon II 64, and
If I am happy with it, i'd like to share it with my relatives and
friends if that is possible or would sharing violate any legal rights
and licenses?

Thank you,
Roger
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Current problem reports assigned to freebsd-arch@FreeBSD.org

2009-12-07T03:06:49Z

struct if_data and ifmibdata

2009-12-03T13:18:08Z

Hi,

I'm currently working on the networking MIBs for bsnmpd to implement the
more recent RFCs (including IPv6 stuff). While doing this I run into
numerous problems accessing interface information. The two sources of this
information are $subj, each of which has some problems. The main problem
is missing flexibility because of ABI issues. I have some ideas how to
relax this somewhat, but before starting to implement anything I though I
ask around whether this makes sense.

1. struct if_data.

This is embedded into struct ifnet, so any change in size changes the
ifnet offsets which is bad once we start keeping the ABI stable in
-current. Other problems are:

- hard to find out what version of struct if_data one is retrieving via
either the if_msghdr routing message or via the interface MIB

- we've run out of ifi_type (u_char) space. IANAIfType is currently at
251. Actually some of our private defines in if_types.h already overlap
IANA assigned types

- ifi_physical is not used anywhere in the kernel as far as I can see
and should probably be removed together with the associated ioctls. This
seems to be replaced long time ago by the if_media stuff.

- we've run out of if_baudrate space (u_long) on 32-bit architectures
for 10GBit/s interfaces

- broadcast packet statistics are missing (they are required by the
actual IF-MIB)

- ifi_datalen is rather short (u_char) and restricts structure size to
256 bytes.

So what I would like to do is:

- add a version field at the beginning and a #define to help user
programs in working with different versions of this structure

- add a couple of dozens of bytes at the end to allow extending the
structure without changing its size

2. struct ifmibdata

- add a version field here too.

3. struct ifmib_iso_8802_3

- add a version field here too.

- add dot3StatsSymbolErrors which are required by the current
EtherLike-MIB.

Unfortunately only 4 drivers actually implement the ethernet statistics
:-( so far

So, does this make any sense?

harti
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: [PATCH] Statclock aliasing by LAPIC

2009-12-01T08:31:56Z

On Wed, 2 Dec 2009, Bruce Evans wrote:

> ... However, the
> defaults with the lapic timer give an even larger beat frequency than
> before, so I don't see how using the lapic timer can increase the
> problem much. (The beat frequency of (1000, 128) is 16000. The beat
> frequency of (1000, 133) is 133000. The latter means that, with
> defaults, statclock and hardclock() ticks are only perfectly synced
> once in every 133 seconds. Misconfiguring hz to a multiple of 128 can
> give perfect synchronization, which may be a more of a problem, or a
> fix -- see below).

PS (the see below part): with perfect sync, statclock() ticks can be
kept perfectly out of phase, and this might work well. E.g.:

(1) hz = 1000, stathz = 125, lapic_timer_hz = 2000: hz ticks on lapic
ticks # 0, 2, 4, ...; stathz ticks on lapic ticks # 7, 15, 23, ...
Malicious programs can still easily hide from statclock().

(2) hz = 100, stathz = 100, lapic_timer hz = 200: hz ticks on lapic
ticks # 0, 2, 4, ...; stathz ticks on lapic ticks # 1, 3, 5, ...
Malicious programs can easily predict statclock(), but can't
easily use more than half of the CPU: e.g.,
- run from hz tick N+epsilon to N+0.5-epsilon (seems to need frequent
clock_gettime() calls to determine when to give up control;
timeouts are no use since none can occur until tick N+1-epsilon)
- usleep(1) and/or give up control to another process. If the
former only, then there can be no timeout until hz tick N+1-epsilon,
and we can hog at most half the CPU. If the latter, then we
will need to find a different one quite often, else the victim
processes will accumulate ticks instead of use and they will be
de-scheduled instead of us. fork() by us must not be cost-free,
else we can generate cooperating victim processes too easily for
this and other types of hogging.

With a randomized statclock(), the randomness would have to be quite
large and not just a small glitch on the increment like I said before,
else maliciousness like in (2) would work to the extent that the
non-glitch part is large.

Bruce
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: [PATCH] Statclock aliasing by LAPIC

2009-12-01T08:01:37Z

BTW, we could also consider using periodic HPET timer (perhaps in legacy mode) for
some of these tasks on modern hardware.

--
Andriy Gapon
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: [PATCH] Statclock aliasing by LAPIC

2009-12-01T07:30:09Z

On Mon, 30 Nov 2009, John Baldwin wrote:

> On Friday 27 November 2009 6:42:50 pm Attilio Rao wrote:
>> Handling all the three clocks (hardclock, softclock, profclock) within
>> the LAPIC can lead to aliasing for the softclock and profclock because
>> hz is sized to fit mainly hardclock. The fashion to handle all of them
>> within the LAPIC was introduced in 2005 and before than the softclock
>> and profclock were supposed to be handled in the rtc. Right now, too,
>> there is the necessary support to handle profclock and statclock in
>> atrtc which gets enabled if the LAPIC signals it can't take in charge
>> the three clocks.
>> The proposed patch reverts the situation preferring the atrtc to
>> handle the statclock and profclock (then a different source from the
>> LAPIC) and then avoid the aliasing problem:

This would defeat most of the point of using the lapic timer. RTC
interrupts are too slow to use for anything if there is an alternative
like the lapic timer. i8254 interrupts are not so bad, and in fact
are just as efficient as lapic timer interrupts iff they are controlled
by the APIC and not by the ATPIC. This is because RTC interrupts must
be acked and tested for in RTC registers, and the RTC is on the ISA
bus so accessing it is very slow, while the i8254 is programmed for
its interrupts to not need any acking or testing. RTC and i8254
interrupts may also be be controlled by the ATPIC, and then the ATPIC
must be acked on the ISA bus too. This gives the following number of
ISA bus accesses for most interrupts:

device read write
------ ---- -----
lapic_timer 0 0
i8254 0 0+0/1
RTC (current) 1 0+0/2
RTC (old) 3 1+0/2

Here "+0/1" and "+0/2" are for the ATPIC ack, if any. RTC (old) is
before I optimized rtcin() to not write the index register in the usual
case where it has not changed (writing the index register takes 1 extra
write and uses 2 dummy reads in an attempt to satisfy timing requirements).
However, there is apparently broken (or just incompatible) hardware
that fails with this optimization. There would probably be more reports
of this brokenness if using the RTC became the default again.

The 4-6 ISA accesses for RTC (old) take about 4-9 usec, so using the
RTC at stathz = 128 Hz takes only 0.05-0.12% of 1 CPU, which is
acceptable. Using the RTC at profhz = 1024 Hz takes 0.4-0.9% of 1
CPU, which may also acceptable, but profhz = 1024 was too slow even
for a 386/20 in 1993; it should be 200-1000 times larger now, but the
RTC just can't support that, and one reason it was never increased is
that the RTC is too inefficient. Profiling can now be implemented
better using the lapic timer, but using the lapic timer currently
implements profiling slightly worse than using the RTC.

> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/statclock_aliasing/statclock_aliasing3.diff
>>
>> In this patch, lapic_setup_clock() has been changed in order to return
>> a three-states variable which identified if the LAPIC got in charge
>> all the three clocks, just the hardclock or none of them (the current
>> situation is just none/all) and the rtc handling runs subsequently.
>> A tunable as been added to force LAPI to get in charge all the three
>> clocks if needed.
>> In ia32 atrtc compiling is linked to atpic compiling, so a compile
>> time flag has been added to check if atpic is not present and in case
>> force LAPIC to take in charge all the three clocks (which is still
>> better than the 'safe belt values' still present in the rtc code).

I don't like tunables, especially to switch from one bug to another.
This can be done better using sysctls only, since it is not needed
for booting. The sysctls would need to be runnable at any time, but
reprogramming the lapic timer at any time is already needed to
fix profiling (cpu_start/stopprofclock() are missing support for
the lapic timer; instead, the default lapic_timer_hz is set excessively
large but not large enough for a good profhz). sysctls also let you
test this stuff without rebooting.

>> Please note that statclock and profclock are widely used in our kernel
>> (rusage is, for example, statclock driven) and fixing this would
>> result in specific improvements (as a several-reported wrong CPU usage
>> statistic in top).
>> This bug has been found by Sandvine Incorporated.

What bug exactly? Bugs like this must have been found before 1993,
since statclock() in 4.4BSD was supposed to fix them. See "A Randomized
Sampling Clock for CPU Utilization Estimation and Code Profiling"
(ftp://ftp.ee.lbl.gov/papers/statclk-usenix93.ps.Z). FreeBSD never
implemented the "Randomized" part, but its statclock() used to sort
of work, since by default stathz was > hz and was not nearly a multiple
of hz. Someone broke the former by increasing the default hz to 1000.
This allowed malicious programs to easily hide themself from statclock()
while consuming a large fraction of CPU cycles (when stathz was > hz,
it was not so easy to hide, and very difficult to both hide and consume
significant CPU, since timeout granularity makes it hard to control
wakeups). Then using the single lapic timer to generate all periodic
timer interrupts increased the synchonization of these interrupts,
thus moving further from a randomized statclock(). However, the
defaults with the lapic timer give an even larger beat frequency than
before, so I don't see how using the lapic timer can increase the
problem much. (The beat frequency of (1000, 128) is 16000. The beat
frequency of (1000, 133) is 133000. The latter means that, with
defaults, statclock and hardclock() ticks are only perfectly synced
once in every 133 seconds. Misconfiguring hz to a multiple of 128 can
give perfect synchronization, which may be a more of a problem, or a
fix -- see below).

>>
>> Reviews, comments and testing are welcome.

Review of the part of the patch visible in the mail:

.

> Presumably in the RTC case lapic_timer_hz should always be hz and not some
> multiple of hz.

Sure. Except the allocation of the timers is backwards at best. You
need profhz on the most efficient timer so that it can be very large
(other changes are required for large profhz to actually work). You
want stathz on the next most efficient timer so that it can be larger
than hz (see above) (other changes are needed for a stathz much larger
than 128 to actually work. Note that at least SCHED_4BSD wants a
scheduling clock frequency of much less than 128 -- it essentially
divides stathz by 8 to get this. Scaling in calcru() is currently
broken after several hundred days of runtime, and would break sooner
with larger stathz).

Perhaps your recent changes (that removed the literal constant dividers)
made the synchronization problem worse. But these changes make it
easy to implement any number of independent timers with optional
randomness using the lapic timer. E.g., to randomize statclock(), just
add a small random value (+-) as well as stathz. Note that statistics
utilities won't like this -- some like systat(1) use statistics ticks
as a timebase so they want statclock() to be perfectly periodic.

I don't worry about the synchronization or broken profiling, and use
lapic_timer_hz = profhz = stathz = hz = 100 whenever the lapic timer
is used. I haven't noticed any problems caused by this (mostly using
SCHED_4BSD), except the unavoidable one that hz = 100 gives less
accurate usr/sys decomposition than does hz = 1000. I have noticed
that this fixed the cosmetic problem that systat(1) shows glitches in
the lapic timer interrupt rates: Although using the lapic timer for
all timer interrupts makes them all perfectly periodic, systat cannot
see this because stathz = 133 is too small a sampling rate and is not
an exact divisor of lapic_timer_hz -- it caused a glitch every
lapic_timer_hz/stathz seconds. For other interrupts, we wouldn't
expect the rates to be constant, but we know that the lapic timer
interrupt rate is constant so we know that the oscillation of its
displayed value is a bug. Right now on ref8-i386.freebsd.org, I see
the values not oscillating much but being weird: for cpu0-1, they are
near 1973; for cpu2-3, they are near 1981; for cpu4-5, they are near
2043, and for cpu6-7 they are near 2003.

A tickless kernel would need to at least consider running the scheduler
and statistics gathering on most context switches (unless it keeps using
ticks when not idle). The scheduler parts of this would also fix
timer synchronization problems for !tickless kernels, but I don't see
how they can be as efficient as only considering scheduling at
infrequent tick intervals.

> Also, did you check to make sure all the lock is present? I
> think at one point I changed the locking for the RTC and/or ISA timer to just
> use critical_enter/exit so that UP machines running an SMP kernel wouldn't pay
> the locking overhead since the code was only used on UP machines. It may very
> well be that I only changed that in a development branch though and not in
> HEAD.

I don't remember any locking changes for RTC ever being committed.
rtcin() still uses mtx_lock_spin(&clock_lock). clock_lock is the i8254
clock's lock, and is still abused for the RTC. This abuse was convenient
when the RTC driver was implemented in the same file as the i8254
driver, but now the RTC driver is in its own file. The i8254's private
variable `clock_lock' is even declared in the RTC driver's public
header, with other style bugs of course.

Bruce
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: sglist(9)

2009-11-30T14:13:19Z

On Nov 30, 2009, at 12:27 PM, John Baldwin wrote:

> On Sunday 29 November 2009 6:27:49 pm Scott Long wrote:
>>> On Wednesday 20 May 2009 2:49:30 pm Jeff Roberson wrote:
>>>> On Tue, 19 May 2009, John Baldwin wrote:
>>>>
>>>> 2) I worry that if all users do sglist_count() followed by a
>>>> dynamic
>>>> allocation and then an _append() they will be very expensive.
>>>> pmap_kextract() is much more expensive than it may first seem to
>>>> be. Do
>>>> you have a user of count already?
>>>
>>> The only one that does now is sglist_build() and nothing currently
>>> uses that.
>>
>> Kinda silly to have it then. I also don't see the point of it; if
>> the
>> point of the sglist object is to avoid VA mappings, then why start
>> with a VA mapping? But that aside, Jeff is correct, sglist_build()
>> is
>> horribly inefficient.
>
> It actually does get used by the nvidia driver, but so far in what I
> have
> done in my jhb_bio branch I have tried several different approaches
> which
> is why the API is as verbose as it is.
>
>>> VOP_GET/PUTPAGES would not need to do this since they could simply
>>> append
>>> the physical addresses extracted directly from vm_page_t's for
>>> example. I'm
>>> not sure this will be used very much now as originally I thought I
>>> would be
>>> changing all storage drivers to do all DMA operations using sglists
>>> and this
>>> sort of thing would have been used for non-bio requests like
>>> firmware
>>> commands; however, as expounded on below, it actually appears better
>>> to
>>> still treat bio's separate from non-bio requests for bus_dma so that
>>> the
>>> non-bio requests can continue to use bus_dmamap_load_buffer() as
>>> they do
>>> now.
>>>
>>
>> I completely disagree with your approach to busdma, but I'll get into
>> that later. What I really don't understand is, why have yet another
>> page description format? Whether the I/O is disk buffers being
>> pushed
>> by a pager to a disk controller, or texture buffers being pushed to
>> video hardware, they already have vm objects associated with them,
>> no? Why translate to an intermediate format? I understand that
>> you're creating another vm object format to deal directly with the
>> needs of nvidia, but that's really a one-off case right now. What
>> about when we want the pagedaemon to push unmapped i/o? Will it have
>> to spend cycles translating its objects to sglists? This is really a
>> larger question that I'm not prepared to answer, but would like to
>> discuss.
>
> Textures do not already have objects associated, no. However, I did
> not
> design sglist with Nvidia in mind. I hacked on it in conjunction with
> phk@, gibbs@, and jeff@ to work on unmapped bio support. That was the
> only motivation for sglist(9). Only the OBJT_SG bits were specific to
> Nvidia and that was added as an afterthought because sglist(9) already
> existed in the jhb_bio branch.
>
> If you look at GETPAGES/PUTPAGES they already deal in terms of
> vm_page_t's,
> not VM objects, and vm_page_t's already provide a linear time way of
> fetching
> the physical address (m->phys_addr), so generating an sglist for
> GETPAGES and
> PUTPAGES will be very cheap. One of the original proposals from
> phk@ was
> actually to pass around arrays of vm_page_t's to describe I/O
> buffers. When
> Poul, Peter, and I talked about it we figured we had a choice
> between passing
> either the physical address or the vm_page_t. However, not all
> physical
> addresses have vm_page_t's, and it was deemed that GEOM's and disk
> drivers did
> not need any properties of the vm_page_t aside from the physical
> address. For
> those reasons, sglist(9) uses physical addresses.
>
>>>> In general I think this is a good idea. It'd be nice to work on
>>>> replacing
>>>> the buf layer's implementation with something like this that could
>>>> be used
>>>> directly by drivers. Have you considered a busdma operation to
>>>> load from
>>>> a sglist?
>>>
>>> So in regards to the bus_dma stuff, I did work on this a while ago
>>> in my
>>> jhb_bio branch. I do have a bus_dmamap_load_sglist() and I had
>>> planned on
>>> using that in storage drivers directly. However, I ended up
>>> circling back
>>> to preferring a bus_dmamap_load_bio() and adding a new 'bio_start'
>>> field
>>> to 'struct bio' that is an offset into an attached sglist.
>>
>> I strongly disagree with forcing busdma to have intimate knowledge of
>> bio's. All of the needed information can be stored in sglist
>> headers.
>
> The alternative is to teach every disk driver to handle the difference
> as well as every GEOM module. Not only that, but it doesn't provide
> any
> easy transition path since you can't change any of the top-level code
> to use an unmapped bio at until all the lower levels have been
> converted
> to handle both ways. Jeff had originally proposed having a
> bus_dmamap_load_bio() and I tried to not use it but just have a
> bus_dmamap_load_sglist() instead, but when I started looking at the
> extra
> work that would have to be duplicated in every driver to handle both
> types
> of bios, I concluded bus_dmamap_load_bio() would actually be a lot
> simpler.

You completely missed the part of my email where I talk about not
having to update drivers for these new APIs.

In any case, I still respectfully disagree with your approach to
busdma and bio handling, and ask that you let Attilio and I work on
our prototype. Once that's done, we can stop talking in hypotheticals.

Scott

_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: sglist(9)

2009-11-30T13:03:46Z

In message <200911301427.23166.jhb@...>, John Baldwin writes:
>On Sunday 29 November 2009 6:27:49 pm Scott Long wrote:

>It actually does get used by the nvidia driver, but so far in what I have
>done in my jhb_bio branch I have tried several different approaches which
>is why the API is as verbose as it is.

I would warn equally against rigorous simplification and gratuitous
generalization in this, I've tried both approaches in prototypes and
neither works out well from an API point of view.

The insight that expended CPU cycles are practially unmeasurable
in this context should not be forgotten, even in the quest to
get ever higher transactions per second numbers.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@... | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: sglist(9)

2009-11-30T11:27:23Z

On Sunday 29 November 2009 6:27:49 pm Scott Long wrote:

> > On Wednesday 20 May 2009 2:49:30 pm Jeff Roberson wrote:
> >> On Tue, 19 May 2009, John Baldwin wrote:
> >>
> >> 2) I worry that if all users do sglist_count() followed by a dynamic
> >> allocation and then an _append() they will be very expensive.
> >> pmap_kextract() is much more expensive than it may first seem to
> >> be. Do
> >> you have a user of count already?
> >
> > The only one that does now is sglist_build() and nothing currently
> > uses that.
>
> Kinda silly to have it then. I also don't see the point of it; if the
> point of the sglist object is to avoid VA mappings, then why start
> with a VA mapping? But that aside, Jeff is correct, sglist_build() is
> horribly inefficient.

It actually does get used by the nvidia driver, but so far in what I have
done in my jhb_bio branch I have tried several different approaches which
is why the API is as verbose as it is.

> > VOP_GET/PUTPAGES would not need to do this since they could simply
> > append
> > the physical addresses extracted directly from vm_page_t's for
> > example. I'm
> > not sure this will be used very much now as originally I thought I
> > would be
> > changing all storage drivers to do all DMA operations using sglists
> > and this
> > sort of thing would have been used for non-bio requests like firmware
> > commands; however, as expounded on below, it actually appears better
> > to
> > still treat bio's separate from non-bio requests for bus_dma so that
> > the
> > non-bio requests can continue to use bus_dmamap_load_buffer() as
> > they do
> > now.
> >
>
> I completely disagree with your approach to busdma, but I'll get into
> that later. What I really don't understand is, why have yet another
> page description format? Whether the I/O is disk buffers being pushed
> by a pager to a disk controller, or texture buffers being pushed to
> video hardware, they already have vm objects associated with them,
> no? Why translate to an intermediate format? I understand that
> you're creating another vm object format to deal directly with the
> needs of nvidia, but that's really a one-off case right now. What
> about when we want the pagedaemon to push unmapped i/o? Will it have
> to spend cycles translating its objects to sglists? This is really a
> larger question that I'm not prepared to answer, but would like to
> discuss.

Textures do not already have objects associated, no. However, I did not
design sglist with Nvidia in mind. I hacked on it in conjunction with
phk@, gibbs@, and jeff@ to work on unmapped bio support. That was the
only motivation for sglist(9). Only the OBJT_SG bits were specific to
Nvidia and that was added as an afterthought because sglist(9) already
existed in the jhb_bio branch.

If you look at GETPAGES/PUTPAGES they already deal in terms of vm_page_t's,
not VM objects, and vm_page_t's already provide a linear time way of fetching
the physical address (m->phys_addr), so generating an sglist for GETPAGES and
PUTPAGES will be very cheap. One of the original proposals from phk@ was
actually to pass around arrays of vm_page_t's to describe I/O buffers. When
Poul, Peter, and I talked about it we figured we had a choice between passing
either the physical address or the vm_page_t. However, not all physical
addresses have vm_page_t's, and it was deemed that GEOM's and disk drivers did
not need any properties of the vm_page_t aside from the physical address. For
those reasons, sglist(9) uses physical addresses.

> >> In general I think this is a good idea. It'd be nice to work on
> >> replacing
> >> the buf layer's implementation with something like this that could
> >> be used
> >> directly by drivers. Have you considered a busdma operation to
> >> load from
> >> a sglist?
> >
> > So in regards to the bus_dma stuff, I did work on this a while ago
> > in my
> > jhb_bio branch. I do have a bus_dmamap_load_sglist() and I had
> > planned on
> > using that in storage drivers directly. However, I ended up
> > circling back
> > to preferring a bus_dmamap_load_bio() and adding a new 'bio_start'
> > field
> > to 'struct bio' that is an offset into an attached sglist.
>
> I strongly disagree with forcing busdma to have intimate knowledge of
> bio's. All of the needed information can be stored in sglist headers.

The alternative is to teach every disk driver to handle the difference
as well as every GEOM module. Not only that, but it doesn't provide any
easy transition path since you can't change any of the top-level code
to use an unmapped bio at until all the lower levels have been converted
to handle both ways. Jeff had originally proposed having a
bus_dmamap_load_bio() and I tried to not use it but just have a
bus_dmamap_load_sglist() instead, but when I started looking at the extra
work that would have to be duplicated in every driver to handle both types
of bios, I concluded bus_dmamap_load_bio() would actually be a lot simpler.

> > This let me
> > carve up I/O requests in geom_dev to satisfy a disk device's max
> > request
> > size while still sharing the same read-only sglist across the various
> > BIO's (by simply adjusting bio_length and bio_start to be a subrange
> > of
> > the sglist) as opposed to doing memory allocations to allocate
> > specific
> > ranges of an sglist (using something like sglist_slice()) for each I/O
> > request.
>
> I think this is fundamentally wrong. You're proposing exchanging a
> cheap operation of splitting VA's with an expensive operation of
> allocating, splitting, copying, and refcounting sglists. Splitting is
> an excessively common operation, and your proposal will impact
> performance as storage becomes exponentially faster.

The whole point is to not do anything to the sglist when splitting up requests
so that it is more efficient. I wrote above that splitting up the sglist
would require allocations and be slow, so I specifically avoided that.
Instead, one just does a simple refcount bump (refcount_acquire()) when
cloning the bio (which is already doing an allocation to get the new bio) and
one does a simple 'bio->bio_start += X' where one already does
bio->bio_data += X' now.

Instead, the sglist describes the "large" buffer at the "top" of the
I/O request tree, and when you split up the large bio into smaller ones
you simply use bio_start and bio_length to specify the sub-range of the
buffer.

> We need to stop thinking about maxio as a roadbump at the bottom of
> the storage stack, and instead think of it as a fundamental attribute
> that is honored at the top when a BIO is created. Instead of loading
> up an sglist with all of the pages (and don't forget coalesced pages
> that might need to be broken up), maybe multiple bio's are created
> that honor maxio from the start, or a single bio with a chained
> sglist, with each chain link honoring maxio, allowing for easy
> splitting.

It may be that the splitting that geom_dev does is done at the wrong layer;
I'm not debating that. :) I attempted to make sglist work efficiently with
what is there now and other things like striping will also want to use cheap
splitting of buffers.

> > I then have bus_dmamap_load_bio() use the subrange of the
> > sglist internally or fall back to using the KVA pointer if the sglist
> > isn't present.
>
> I completely disagree. Drivers already deal with the details of
> bio's, and should continue to do so. If a driver gets a bio that has
> a valid bio_data pointer, it should call bus_dmamap_load(). If it
> get's one with a valid sglist, it should call bus_dmamap_load_sglist
> (). Your proposal means that every storage driver in the system will
> have to change to use bus_dmamap_load_bio(). It's not a big change,
> but it's disruptive both in the tree and out. Your proposal also
> implies that CAM will have to start carrying BIO's in CCBs and passing
> them to their SIMs. I absolutely disagree with this.

Ok. As I mentioned above, while this does add churn, I think it is less
churn than changing all the drivers to handle the two different types of
bio requests. I also think it is much less friendly to doing the unmapped
I/O changes in stages that allows the work to progress in parallel in
different areas. I also believe I specifically mentioned changing CCBs to
pass the bio instead of the raw (data, length) pair when I discussed this
with folks earlier.

> If we keep unneeded complications out of busdma, we avoid a lot of
> churn. We also leave the busdma interface available for other forms
> of I/O without requiring more specific APi additions to accommodate
> them. What about unmapped network i/o coming from something like
> sendfile?

I do have a bus_dmamap_load_sglist() in my tree already. Do note that we
already have bus_dmamap_load_mbuf() and bus_dmamap_load_uio(), so there is
precedent for letting bus_dma handle slightly more complex data structures
than just a (buffer, length) pair.

> > However, I'm not really trying to get the bio stuff into the tree,
> > this
> > is mostly for the Nvidia case and for that use case the driver is
> > simply
> > creating simple single-entry lists and using sglist_append_phys().
> >
>
> Designing the whole API around a single driver that we can't even get
> the source to makes it hard to evaluate the API.

The API was designed for the bio stuff, and not for any specific driver. The
Nvidia stuff was only done as an afterthought because the sglist(9) structure
already existed at the time. It was also designed as a result of the
discussions among several people and not completely in a vacuum.

> Attilio and I have spoken about this in private and will begin work on
> a prototype. Here is the outline of what we're going to do:

For those playing along at home, the things that I suggested to Attilio as far
as the next steps that I would do were to add the following APIs and then make
the necessary changes so that drivers and GEOM modules use these:

- bus_dmamap_load_bio(): Fairly simple. Just takes a bio instead of (buffer,
length).
- bio_adjust(): This is a lot like m_adj() but for bio's instead of mbuf's.
It can be inline, but the point is to have GEOM modules use this to split up
a bio buffer instead of directly manipulating bio_data and bio_length
(possibly bio_offset as well).

Once these changes are done, adding support for simple unmapped bio's
consists of adding sglist support to bus_dma for each architecture and
bus_dmamap_load_bio() on each arch. Then upper layer code could start using
unmapped bios after that (I had hacky prototype changes to physio).

There would still be several big things to work out, such as GEOM modules
that need to manipulate the data and not just pass it through. phk's
suggestion here was to have the driver or GEOM module fail the request with a
magic error code. The originator was then supposed to map the buffer and
retry the request. Presumably one could note the first time a given device
object failed a request that way and always send down mapped requests
afterwards to avoid delays in subsequent I/O requests. There are other ways
of handling this problem as well I imagine. I have not made any attempt to
solve this problem.

Also, the changes Jeff has discussed with regards to tearing up
getpages/putpages and the buffer cache in general to take advantage of
unmapped bios are a separate animal that would build on this stuff further.
I have not made any attempt at this either.

I do find the idea of chaining sglist's together interesting. It would lose
one of the "benefits" of the current layout which is that the segment array is
ABI-compatible with bus_dma's S/G list format so that in the common case the
sglist that physio or getpages/putpages would generate could be passed
directly to the device driver's bus_dma callback without having to generate an
intermediate data structure.

--
John Baldwin
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: [PATCH] Statclock aliasing by LAPIC

2009-11-30T10:05:30Z

On Friday 27 November 2009 6:42:50 pm Attilio Rao wrote:

> Handling all the three clocks (hardclock, softclock, profclock) within
> the LAPIC can lead to aliasing for the softclock and profclock because
> hz is sized to fit mainly hardclock. The fashion to handle all of them
> within the LAPIC was introduced in 2005 and before than the softclock
> and profclock were supposed to be handled in the rtc. Right now, too,
> there is the necessary support to handle profclock and statclock in
> atrtc which gets enabled if the LAPIC signals it can't take in charge
> the three clocks.
> The proposed patch reverts the situation preferring the atrtc to
> handle the statclock and profclock (then a different source from the
> LAPIC) and then avoid the aliasing problem:
>

http://www.freebsd.org/~attilio/Sandvine/STABLE_8/statclock_aliasing/statclock_aliasing3.diff

>
> In this patch, lapic_setup_clock() has been changed in order to return
> a three-states variable which identified if the LAPIC got in charge
> all the three clocks, just the hardclock or none of them (the current
> situation is just none/all) and the rtc handling runs subsequently.
> A tunable as been added to force LAPI to get in charge all the three
> clocks if needed.
> In ia32 atrtc compiling is linked to atpic compiling, so a compile
> time flag has been added to check if atpic is not present and in case
> force LAPIC to take in charge all the three clocks (which is still
> better than the 'safe belt values' still present in the rtc code).
>
> Please note that statclock and profclock are widely used in our kernel
> (rusage is, for example, statclock driven) and fixing this would
> result in specific improvements (as a several-reported wrong CPU usage
> statistic in top).
> This bug has been found by Sandvine Incorporated.
>
> Reviews, comments and testing are welcome.

Presumably in the RTC case lapic_timer_hz should always be hz and not some
multiple of hz. Also, did you check to make sure all the lock is present? I
think at one point I changed the locking for the RTC and/or ISA timer to just
use critical_enter/exit so that UP machines running an SMP kernel wouldn't pay
the locking overhead since the code was only used on UP machines. It may very
well be that I only changed that in a development branch though and not in
HEAD.

--
John Baldwin
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Current problem reports assigned to freebsd-arch@FreeBSD.org

2009-11-30T03:06:47Z

Re: sglist(9)

2009-11-29T16:47:08Z

On Nov 29, 2009, at 5:40 PM, Scott Long wrote:

> On Nov 29, 2009, at 5:06 PM, Julian Elischer wrote:
>> Scott Long wrote:
>>
>>> I think this is fundamentally wrong. You're proposing exchanging
>>> a cheap operation of splitting VA's with an expensive operation of
>>> allocating, splitting, copying, and refcounting sglists.
>>> Splitting is an excessively common operation, and your proposal
>>> will impact performance as storage becomes exponentially faster.
>>
>> From the perspective of a flashdrive driver the more
>> efficient the better. The current generation of devices are
>> doing 800MB/sec (6.4Gb/sec) of scattter-gather random IO
>> and really that will only go up. We are doing over 130,000
>> independent
>> transactions per second and we can put multiple drives in a single
>> machine.
>>
>> These numbers will only increase with future developments.
>
> MB/s doesn't tell me much other than the memory bandwidth of the
> pathways (and that that DMA engines involved don't completely
> suck). What about transactions/sec? That tells me a lot more about
> the efficiency of the OS, drivers, and firmware, as well as latency.
>
>

Bah, the answer was right in front of me, sorry =-) 130k is impressive.

Scott

_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: sglist(9)

2009-11-29T16:40:12Z

On Nov 29, 2009, at 5:06 PM, Julian Elischer wrote:

> Scott Long wrote:
>
>> I think this is fundamentally wrong. You're proposing exchanging a
>> cheap operation of splitting VA's with an expensive operation of
>> allocating, splitting, copying, and refcounting sglists. Splitting
>> is an excessively common operation, and your proposal will impact
>> performance as storage becomes exponentially faster.
>
> From the perspective of a flashdrive driver the more
> efficient the better. The current generation of devices are
> doing 800MB/sec (6.4Gb/sec) of scattter-gather random IO
> and really that will only go up. We are doing over 130,000 independent
> transactions per second and we can put multiple drives in a single
> machine.
>
> These numbers will only increase with future developments.

MB/s doesn't tell me much other than the memory bandwidth of the
pathways (and that that DMA engines involved don't completely suck).
What about transactions/sec? That tells me a lot more about the
efficiency of the OS, drivers, and firmware, as well as latency.

Scott

_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: sglist(9)

2009-11-29T16:06:02Z

Scott Long wrote:

> I think this is fundamentally wrong. You're proposing exchanging a
> cheap operation of splitting VA's with an expensive operation of
> allocating, splitting, copying, and refcounting sglists. Splitting is
> an excessively common operation, and your proposal will impact
> performance as storage becomes exponentially faster.
>

From the perspective of a flashdrive driver the more
efficient the better. The current generation of devices are
doing 800MB/sec (6.4Gb/sec) of scattter-gather random IO
and really that will only go up. We are doing over 130,000 independent
transactions per second and we can put multiple drives in a single
machine.

These numbers will only increase with future developments.
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: sglist(9)

2009-11-29T15:27:49Z

John,

Sorry for the late reply on this. Attilio approached me recently
about moving busdma and storage to sglists; up until then I had
largely ignored this conversation because I thought that it was only
about the nvidia driver.

> On Wednesday 20 May 2009 2:49:30 pm Jeff Roberson wrote:
>> On Tue, 19 May 2009, John Baldwin wrote:
>>
>> 2) I worry that if all users do sglist_count() followed by a dynamic
>> allocation and then an _append() they will be very expensive.
>> pmap_kextract() is much more expensive than it may first seem to
>> be. Do
>> you have a user of count already?
>
> The only one that does now is sglist_build() and nothing currently
> uses that.

Kinda silly to have it then. I also don't see the point of it; if the
point of the sglist object is to avoid VA mappings, then why start
with a VA mapping? But that aside, Jeff is correct, sglist_build() is
horribly inefficient.

> VOP_GET/PUTPAGES would not need to do this since they could simply
> append
> the physical addresses extracted directly from vm_page_t's for
> example. I'm
> not sure this will be used very much now as originally I thought I
> would be
> changing all storage drivers to do all DMA operations using sglists
> and this
> sort of thing would have been used for non-bio requests like firmware
> commands; however, as expounded on below, it actually appears better
> to
> still treat bio's separate from non-bio requests for bus_dma so that
> the
> non-bio requests can continue to use bus_dmamap_load_buffer() as
> they do
> now.
>

I completely disagree with your approach to busdma, but I'll get into
that later. What I really don't understand is, why have yet another
page description format? Whether the I/O is disk buffers being pushed
by a pager to a disk controller, or texture buffers being pushed to
video hardware, they already have vm objects associated with them,
no? Why translate to an intermediate format? I understand that
you're creating another vm object format to deal directly with the
needs of nvidia, but that's really a one-off case right now. What
about when we want the pagedaemon to push unmapped i/o? Will it have
to spend cycles translating its objects to sglists? This is really a
larger question that I'm not prepared to answer, but would like to
discuss.

>> 3) Rather than having sg_segs be an actual pointer, did you consider
>> making it an unsized array? This removes the overhead of one
>> pointer from
>> the structure while enforcing that it's always contiguously
>> allocated.
>
> It's actually a feature to be able to have the header in separate
> storage from
> segs array. I use this in the jhb_bio branch in the bus_dma
> implementations
> where a pre-allocated segs array is stored in the bus dma tag and
> the header
> is allocated on the stack.
>

I'd like to take this one step further. Instead of sglists being
exactly sized, I'd like to see them be much more like mbufs, with a
header and static storage, maybe somewhere between 128b and 1k in
total size. Then they can be allocated and managed in pools, and
chained together to make for easy appending, splitting, and growing.
Offset pointers can be stored in the header instead of externally.
Also, there are a lot of failure points in the API regarding to the
sglist object being too small. Those need to be fixed.

>> 4) SGLIST_INIT might be better off as an inline, and may not even
>> belong
>> in the header file.
>
> That may be true. I currently only use it in the jhb_bio branch for
> the
> bus_dma implementations.
>
>> In general I think this is a good idea. It'd be nice to work on
>> replacing
>> the buf layer's implementation with something like this that could
>> be used
>> directly by drivers. Have you considered a busdma operation to
>> load from
>> a sglist?
>
> So in regards to the bus_dma stuff, I did work on this a while ago
> in my
> jhb_bio branch. I do have a bus_dmamap_load_sglist() and I had
> planned on
> using that in storage drivers directly. However, I ended up
> circling back
> to preferring a bus_dmamap_load_bio() and adding a new 'bio_start'
> field
> to 'struct bio' that is an offset into an attached sglist.

I strongly disagree with forcing busdma to have intimate knowledge of
bio's. All of the needed information can be stored in sglist headers.

> This let me
> carve up I/O requests in geom_dev to satisfy a disk device's max
> request
> size while still sharing the same read-only sglist across the various
> BIO's (by simply adjusting bio_length and bio_start to be a subrange
> of
> the sglist) as opposed to doing memory allocations to allocate
> specific
> ranges of an sglist (using something like sglist_slice()) for each I/O
> request.

I think this is fundamentally wrong. You're proposing exchanging a
cheap operation of splitting VA's with an expensive operation of
allocating, splitting, copying, and refcounting sglists. Splitting is
an excessively common operation, and your proposal will impact
performance as storage becomes exponentially faster.

We need to stop thinking about maxio as a roadbump at the bottom of
the storage stack, and instead think of it as a fundamental attribute
that is honored at the top when a BIO is created. Instead of loading
up an sglist with all of the pages (and don't forget coalesced pages
that might need to be broken up), maybe multiple bio's are created
that honor maxio from the start, or a single bio with a chained
sglist, with each chain link honoring maxio, allowing for easy
splitting.

> I then have bus_dmamap_load_bio() use the subrange of the
> sglist internally or fall back to using the KVA pointer if the sglist
> isn't present.

I completely disagree. Drivers already deal with the details of
bio's, and should continue to do so. If a driver gets a bio that has
a valid bio_data pointer, it should call bus_dmamap_load(). If it
get's one with a valid sglist, it should call bus_dmamap_load_sglist
(). Your proposal means that every storage driver in the system will
have to change to use bus_dmamap_load_bio(). It's not a big change,
but it's disruptive both in the tree and out. Your proposal also
implies that CAM will have to start carrying BIO's in CCBs and passing
them to their SIMs. I absolutely disagree with this.

If we keep unneeded complications out of busdma, we avoid a lot of
churn. We also leave the busdma interface available for other forms
of I/O without requiring more specific APi additions to accommodate
them. What about unmapped network i/o coming from something like
sendfile?

>
> However, I'm not really trying to get the bio stuff into the tree,
> this
> is mostly for the Nvidia case and for that use case the driver is
> simply
> creating simple single-entry lists and using sglist_append_phys().
>

Designing the whole API around a single driver that we can't even get
the source to makes it hard to evaluate the API.

Attilio and I have spoken about this in private and will begin work on
a prototype. Here is the outline of what we're going to do:

1. Change struct sglist as so:
a. Uniform size
b. Determine an optimal number of elements to include in the size
(waving my hands here, more research is needed).
c. Chain, offset, and length pointers, very similar to how mbufs
already work
2. Expand the sglist API so that I/O producers can allocate slabs of
sglists and slice them up into pools that they can manage and own
3. Add an sglist field to struct bio, and add appropriate flags to
identify VA vs sglist operation
4. Extend the CAM_DATA_PHYS attributes in CAM to handle sglists.
5. Add bus_dmamap_load_sglist(). This will be able to walk chains
and combine, split, and reassign segments as needed.
6. Modify a select number of drivers to use it.
7. Add a flag to disk->d_flags to signal if a driver can handle
sglists. Have geom_dev look at this flag and generate a
kmem_alloc_nofault+pmap_kenter sequence for drivers that can't support
it.

In the end, no drivers will need to change, but the ones that do
change will obviously benefit. We're going to prototype this will an
i/o source that starts unmapped (via the Xen blkback driver). The
downside is that most GEOM transforms that need to touch the data
won't work, but that's something that can be addressed once the
prototype is done and evaluated.

Scott

_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[[atch] Re: anyone interested in helping fixing the 'tcc' compiler ?

2009-11-28T10:50:04Z

followup to myself due to scarce success...
I have done some partial step in fixing the ELF produced by tcc
to work with freebsd. A patch is attached which works for simple
programs but not for more complex ones.

I found the following problems:
- tcc does not produce a PHDR program header, which caused the
linker to fail. This should be fixed by this patch.

- the relocation sections produced by tcc apparently include a
mix of JMP and non JMP relocations in the same place.
Our loader complains when it finds this mix.
I have changed the section definitions but it seems to work
only for simple things (Hello World -style).

- the relocation info is not in the place rtld is looking for.
What i found is that UNDEF symbols had the offset to be
patched in the dynsym section, instead of the .got section where
(apparently) our loader is looking for. The function
patch_dynsym_undef() in the patch attached seems to handle this,
but I am not sure how general is this.

With this patch the simplest example programs (ex1, ex2, ex3, ex5)
do work, but ex4 (which uses -lX11) fails to load
ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/i386/reloc.c:292
(I hope i can track this later).

cheers
luigi

On Sun, Nov 22, 2009 at 12:17:32PM +0100, Luigi Rizzo wrote:

> Hi,
> I have recently started playing with the Tiny C Compuler (lang/tcc)
> which is amazingly useful for prototyping, but has problem generating
> non-static binaries in FreeBSD -- basically it produces a bogus
> elf file which our loader does not like.
> Static binaries work fine, as well as 'tcc -run ' (compile
> and run on the fly -- you should really try it if you haven't yet).
>
> There is an open PR on this
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=138481
>
> and the problem is known upstream but no fix
>
> http://lists.gnu.org/archive/html/tinycc-devel/2005-07/msg00070.html
>
> However, from the description it does not seem a horribly
> hard problem. Perhaps someone with a bit of knowledge on
> how our ld-elf.so works should not have a hard time pinpointing
> the problem so that other people can fix it ?
>
> Any takers ?
>
> cheers
> luigi

_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: [gonzo@freebsd.org: [RFC] GPIO framework]

2009-11-27T16:02:54Z

Marc Balmer wrote:

> Oleksandr Tymoshenko schrieb:
>> Forwarding RFC to embedded@ because there was typo in Cc address in
>> the original message :(
>>
>> ----- Forwarded message from Oleksandr Tymoshenko <gonzo@...>
>> -----
>>
>> Date: Thu, 26 Nov 2009 06:57:36 +0200
>> From: Oleksandr Tymoshenko <gonzo@...>
>> To: arch@...
>> Cc: embedded@...
>> Subject: [RFC] GPIO framework
>> User-Agent: Mutt/1.5.20 (2009-06-14)
>>
>> Recently I've been working on GPIO framework that, I believe, is much
>> needed for embedded applications of FreeBSD. Now framework
>> is mature enough to show it to the world, so this is my request for
>> review.
>>
>> Patch: http://people.freebsd.org/~gonzo/mips/gpio.diff
>> sys/gpio.h is based on the same file from NetBSD but all the other
>> files have been written from the scratch.
>
> why that?

Because the hard stuff is hwpart <-> bus <-> devices hierarchy and
their interoperability. For these I wanted to use kobj/newbus API and
it's not available in NetBSD. The rest of the code is relatively
simple.

>> Description:
>>
>> GPIO stands for General Purpose Input/Output. This interface may be
>> thought of as a set of pins which could serve as input or output
>> having logical 0 and logical 1 as their values (some other options
>> are applicable, but they're not crucial for this explanation).
>> Most common usage of GPIO interface is LED and button control for
>> various SoCs.
>
> we do much more, since years: we attach I2C buses over GPIO, or 1-Wire
> buses. GPIO is not just for LEDs.

I know, these two were picked as an example.

>> Reference implementation of child device is sys/dev/gpio/gpioled.c
>> It provides on/off function for led(4) API
>>
>> Any comments/feedback are welcome
>>
>
> it suffers from the same problems my implementation in other BSD
> suffers: No interrupt capabilities, no capability to build buses wider
> than 1 bit.
Adding interrupts should not be an issue. Child devices setup
handlers on gpiobus using bus_setup_intr. HW implementation
catches interrupts and reports pins to gpiobus via GPIOBUS_INTR()
method and then bus dispatches interrupts to child devices. There
might be some hidden pitfalls but I can't tell them from the top of my
head. Some additional info on interrupts/userland interaction here:
http://lists.freebsd.org/pipermail/freebsd-arch/2009-November/009711.html

Could you elaborate on multi-bit buses? I'm not well acquainted
with this area so any examples would help :)

> your gpioctl command line syntax is not nice.
Why? Since there is no need for complex rule language as in, for
instance, ipfw I decided to use traditional getopt approach.

> I suggest you take a closer look at gpio in NetBSD and that we work
> together on this. My offer stands.
I appreciate your offer but as it was mentioned above the most
vital part is not OS-independent and it makes adopting NetBSD gpio
framework somewhat complicated.

Having ioctl-wise compatibility may turn out useful though. I'll think
about it.
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[PATCH] Statclock aliasing by LAPIC

2009-11-27T15:42:50Z

Handling all the three clocks (hardclock, softclock, profclock) within
the LAPIC can lead to aliasing for the softclock and profclock because
hz is sized to fit mainly hardclock. The fashion to handle all of them
within the LAPIC was introduced in 2005 and before than the softclock
and profclock were supposed to be handled in the rtc. Right now, too,
there is the necessary support to handle profclock and statclock in
atrtc which gets enabled if the LAPIC signals it can't take in charge
the three clocks.
The proposed patch reverts the situation preferring the atrtc to
handle the statclock and profclock (then a different source from the
LAPIC) and then avoid the aliasing problem:
http://www.freebsd.org/~attilio/Sandvine/STABLE_8/statclock_aliasing/statclock_aliasing3.diff

In this patch, lapic_setup_clock() has been changed in order to return
a three-states variable which identified if the LAPIC got in charge
all the three clocks, just the hardclock or none of them (the current
situation is just none/all) and the rtc handling runs subsequently.
A tunable as been added to force LAPI to get in charge all the three
clocks if needed.
In ia32 atrtc compiling is linked to atpic compiling, so a compile
time flag has been added to check if atpic is not present and in case
force LAPIC to take in charge all the three clocks (which is still
better than the 'safe belt values' still present in the rtc code).

Please note that statclock and profclock are widely used in our kernel
(rusage is, for example, statclock driven) and fixing this would
result in specific improvements (as a several-reported wrong CPU usage
statistic in top).
This bug has been found by Sandvine Incorporated.

Reviews, comments and testing are welcome.

Thanks,
Attilio

--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: [RFC] GPIO framework

2009-11-26T08:52:21Z

>
> Are there any functions to setup interrupts on GPIO pins?
Not at the moment, but I plan to add interrupt support later.
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."