Re: Aligned operations mismatch

2018-08-22 Thread Sebastian Huber 

On 23/08/18 07:29, Sebastian Huber wrote:

Hello,

On 22/08/18 16:49, Mikhail Svetkin wrote:

Hi all,

I have found a problem with assembler code generation in network 
stack on ARM processor (aligment fault).


I am using:
arm-rtems5-gcc (GCC) 7.2.0 20170814 (RTEMS 5, RSB 
a6d011e028a0776cedf0823940eb882e917a44e5, Newlib 2.5.0.20170922)


The compiler generates invalid instruction 'ldmia' here 
(https://git.rtems.org/rtems/tree/cpukit/libnetworking/netinet/udp_usrreq.c#n160).


The instruction does not support unaligned accesses.

Also i have found the bug fix in FreeBSD repository 
(https://github.com/freebsd/freebsd/commit/6cc0e8d2a0b583db5707f811d4ebfbe1ad05e628)


this is a three year old commit. Which libbsd version do you use? This 
fix is included in the libbsd 4.11 and master branch.




Oh, I should have read the URL more carefully. You use the legacy 
network stack. Please open a ticket for this.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Aligned operations mismatch

2018-08-22 Thread Amaan Cheval 
On Wed, Aug 22, 2018 at 8:20 PM Mikhail Svetkin
 wrote:
>
> Hi all,
>
> I have found a problem with assembler code generation in network stack on ARM 
> processor (aligment fault).
>
> I am using:
> arm-rtems5-gcc (GCC) 7.2.0 20170814 (RTEMS 5, RSB 
> a6d011e028a0776cedf0823940eb882e917a44e5, Newlib 2.5.0.20170922)
>
> The compiler generates invalid instruction 'ldmia' here 
> (https://git.rtems.org/rtems/tree/cpukit/libnetworking/netinet/udp_usrreq.c#n160).
>
> The instruction does not support unaligned accesses.
>
> Also i have found the bug fix in FreeBSD repository 
> (https://github.com/freebsd/freebsd/commit/6cc0e8d2a0b583db5707f811d4ebfbe1ad05e628)
>
> I tried their solution and it works.
>

Do you mean you changed the alignment to 2 in RTEMS'
cpukit/libnetworking/netinet/ip.h:85?
https://git.rtems.org/rtems/tree/cpukit/libnetworking/netinet/ip.h#n85

If yes, and if you could confirm it worked / tests passed, feel free
to submit a patch: https://devel.rtems.org/wiki/Developer/Contributing

If not, a ticket with all the information is highly appreciated too!

P.S. - I believe this is a part of the "old" networking stack for
RTEMS - the "new" stack uses rtems-libbsd, which already includes the
FreeBSD patch you mentioned:
https://github.com/RTEMS/rtems-libbsd/blob/master/freebsd/sys/netinet/ip.h#L70

Perhaps someone can shed some light on when the old stack can be used
vs. the new one, and how - I haven't seen much documentation on it.
Patch fixes for the old stack should likely still be accepted while
there are still BSPs using it.

> Should I create a ticket for that?
>
> Best regards,
> Mikhail
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Aligned operations mismatch

2018-08-22 Thread Sebastian Huber 

Hello,

On 22/08/18 16:49, Mikhail Svetkin wrote:

Hi all,

I have found a problem with assembler code generation in network stack 
on ARM processor (aligment fault).


I am using:
arm-rtems5-gcc (GCC) 7.2.0 20170814 (RTEMS 5, RSB 
a6d011e028a0776cedf0823940eb882e917a44e5, Newlib 2.5.0.20170922)


The compiler generates invalid instruction 'ldmia' here 
(https://git.rtems.org/rtems/tree/cpukit/libnetworking/netinet/udp_usrreq.c#n160).


The instruction does not support unaligned accesses.

Also i have found the bug fix in FreeBSD repository 
(https://github.com/freebsd/freebsd/commit/6cc0e8d2a0b583db5707f811d4ebfbe1ad05e628)


this is a three year old commit. Which libbsd version do you use? This 
fix is included in the libbsd 4.11 and master branch.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Some problems with the libbsd update

2018-08-22 Thread Sebastian Huber 

On 23/08/18 01:13, Joel Sherrill wrote:



On Wed, Aug 22, 2018 at 6:00 PM, Chris Johns > wrote:


On 22/08/2018 22:25, Sebastian Huber wrote:
> On 22/08/18 14:06, Joel Sherrill wrote:
>> On Wed, Aug 22, 2018, 6:47 AM Sebastian Huber
>> mailto:sebastian.hu...@embedded-brains.de>
>> >> wrote:
>>
>> It really is necessary to know how the other architectures implement it. 
Some
>> may turn out to be easy. Others like Epiphany and new may never
matter.
>
> If the niche architectures don't use libbsd (which I guess is
the case), then
> there is no issue at all.
>

Do we document what is supported and what is not supported?


This was largely the point of my response. We don't have a master list of
at least the following information:

+ Architectures that support SMP and tested to N cores
+ Architectures that support TLS


We have the CPU Supplement.


+ Architectures that support libbsd

A user can't determine what is usable to them in for at least those
features. We need a basic feature table of at least the above
for users.


I think a better question is what do I have to provide to get libbsd 
support? This is currently not that much. You just need the interrupt 
extensions API. After the update to a new FreeBSD version you probably 
need also TLS and maybe uni-processor architectures are no longer 
supported. You can still use the current libbsd.




Beyond that, I would consider TLS a hidden basic feature since I think
we now rely on it in some infrastructure pieces (language run-times?).
We don't have ticket(s) related to which architectures need it added.
And no notes on how to extract the details on what to do from GCC.
I randomly checked gcc for the nios2 and guess that this is the
register:

   (TP_REGNO              23)   ; Thread pointer register

How I am supposed to figure that out reliably, I am not sure.

I checked the bfin and don't get any hits for tls/TLS or THREAD_LOCAL.
Perhaps it doesn't support it at all. Who knows?


You have to check the ABI document.




Does libbsd have suitable checks on the built RTEMS to know it
cannot be supported?


Without the above table, I am not sure how. Curious to hear 
Sebastian's answer.



FWIW I do not think the idea of "one size fits all" is workable. I
think a
number of architectures would benefit from a different smaller
networking stack.


+1

We are in a position where we need begin to deprecate the old stack to 
BSPs
that currently support it -- perhaps move it to a separate build tree. 
And

more seriously consider LWIP.

An even when an architecture has the infrastructure, there is at least the
SPARC which I don't think have any Nexus devices or drivers for libbsd.


The generic nexus device which works well on SPARC. We used the libbsd 
on a SPARC project.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Some problems with the libbsd update

2018-08-22 Thread Chris Johns 
On 23/08/2018 15:09, Sebastian Huber wrote:
> On 23/08/18 01:00, Chris Johns wrote:
>> On 22/08/2018 22:25, Sebastian Huber wrote:
>>> On 22/08/18 14:06, Joel Sherrill wrote:
 On Wed, Aug 22, 2018, 6:47 AM Sebastian Huber
 >>> > wrote:

 It really is necessary to know how the other architectures implement it. 
 Some
 may turn out to be easy. Others like Epiphany and new may never matter.
>>> If the niche architectures don't use libbsd (which I guess is the case), 
>>> then
>>> there is no issue at all.
>>>
>> Do we document what is supported and what is not supported?
> 
> The status of the SMP and TLS support is documented in the CPU Supplement.
> 
> We added the TLS support for ARM, m68k, PowerPC and SPARC in January 2014 and
> also recently for RISC-V. TLS is a C11 standard element. All RTEMS 
> architectures
> which don't support it have a maintainer problem from my point of view.
> 

Thanks

>>
>> Does libbsd have suitable checks on the built RTEMS to know it cannot be
>> supported?
> 
> One way to figure out if it basically works is to run the tests.
> 

I am referring to a configure type test. See the opts types tests rtems_waf
already supports, for example SMP.

>>
>> FWIW I do not think the idea of "one size fits all" is workable. I think a
>> number of architectures would benefit from a different smaller networking 
>> stack.
> 
> libbsd is not only a network stack. It contains also USB and MMC card 
> support. I
> work on a port of the NVMe support currently.
> 
> FreeBSD seems to receive a huge funding from CDN providers such as Netfix and
> Limelight Networks. They probably don't care about uni-processor system 
> support
> at all. The use of lock-free data structures (Concurrency Kit) and the epoch
> memory reclamation are now a mandatory infrastructure. There is no FreeBSD
> configuration option to avoid this. This was a bit surprising to me. It was 
> also
> introduced less than half a year before the planned FreeBSD 12 release.
> 
> The recent changes in FreeBSD make the lwIP network stack even more attractive
> for low-end targets.

Yes.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Some problems with the libbsd update

2018-08-22 Thread Sebastian Huber 

On 23/08/18 01:00, Chris Johns wrote:

On 22/08/2018 22:25, Sebastian Huber wrote:

On 22/08/18 14:06, Joel Sherrill wrote:

On Wed, Aug 22, 2018, 6:47 AM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>> wrote:

It really is necessary to know how the other architectures implement it. Some
may turn out to be easy. Others like Epiphany and new may never matter.

If the niche architectures don't use libbsd (which I guess is the case), then
there is no issue at all.


Do we document what is supported and what is not supported?


The status of the SMP and TLS support is documented in the CPU Supplement.

We added the TLS support for ARM, m68k, PowerPC and SPARC in January 
2014 and also recently for RISC-V. TLS is a C11 standard element. All 
RTEMS architectures which don't support it have a maintainer problem 
from my point of view.




Does libbsd have suitable checks on the built RTEMS to know it cannot be 
supported?


One way to figure out if it basically works is to run the tests.



FWIW I do not think the idea of "one size fits all" is workable. I think a
number of architectures would benefit from a different smaller networking stack.


libbsd is not only a network stack. It contains also USB and MMC card 
support. I work on a port of the NVMe support currently.


FreeBSD seems to receive a huge funding from CDN providers such as 
Netfix and Limelight Networks. They probably don't care about 
uni-processor system support at all. The use of lock-free data 
structures (Concurrency Kit) and the epoch memory reclamation are now a 
mandatory infrastructure. There is no FreeBSD configuration option to 
avoid this. This was a bit surprising to me. It was also introduced less 
than half a year before the planned FreeBSD 12 release.


The recent changes in FreeBSD make the lwIP network stack even more 
attractive for low-end targets.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Some problems with the libbsd update

2018-08-22 Thread Joel Sherrill 
On Wed, Aug 22, 2018 at 6:00 PM, Chris Johns  wrote:

> On 22/08/2018 22:25, Sebastian Huber wrote:
> > On 22/08/18 14:06, Joel Sherrill wrote:
> >> On Wed, Aug 22, 2018, 6:47 AM Sebastian Huber
> >>  >> > wrote:
> >>
> >> It really is necessary to know how the other architectures implement
> it. Some
> >> may turn out to be easy. Others like Epiphany and new may never matter.
> >
> > If the niche architectures don't use libbsd (which I guess is the case),
> then
> > there is no issue at all.
> >
>
> Do we document what is supported and what is not supported?
>

This was largely the point of my response. We don't have a master list of
at least the following information:

+ Architectures that support SMP and tested to N cores
+ Architectures that support TLS
+ Architectures that support libbsd

A user can't determine what is usable to them in for at least those
features. We need a basic feature table of at least the above
for users.

Beyond that, I would consider TLS a hidden basic feature since I think
we now rely on it in some infrastructure pieces (language run-times?).
We don't have ticket(s) related to which architectures need it added.
And no notes on how to extract the details on what to do from GCC.
I randomly checked gcc for the nios2 and guess that this is the
register:

   (TP_REGNO  23)   ; Thread pointer register

How I am supposed to figure that out reliably, I am not sure.

I checked the bfin and don't get any hits for tls/TLS or THREAD_LOCAL.
Perhaps it doesn't support it at all. Who knows?



>
> Does libbsd have suitable checks on the built RTEMS to know it cannot be
> supported?
>

Without the above table, I am not sure how. Curious to hear Sebastian's
answer.


>
> FWIW I do not think the idea of "one size fits all" is workable. I think a
> number of architectures would benefit from a different smaller networking
> stack.
>

+1

We are in a position where we need begin to deprecate the old stack to BSPs
that currently support it -- perhaps move it to a separate build tree. And
more seriously consider LWIP.

An even when an architecture has the infrastructure, there is at least the
SPARC which I don't think have any Nexus devices or drivers for libbsd.




>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Some problems with the libbsd update

2018-08-22 Thread Chris Johns 
On 22/08/2018 22:25, Sebastian Huber wrote:
> On 22/08/18 14:06, Joel Sherrill wrote:
>> On Wed, Aug 22, 2018, 6:47 AM Sebastian Huber
>> > > wrote:
>>
>> It really is necessary to know how the other architectures implement it. Some
>> may turn out to be easy. Others like Epiphany and new may never matter.
> 
> If the niche architectures don't use libbsd (which I guess is the case), then
> there is no issue at all.
> 

Do we document what is supported and what is not supported?

Does libbsd have suitable checks on the built RTEMS to know it cannot be 
supported?

FWIW I do not think the idea of "one size fits all" is workable. I think a
number of architectures would benefit from a different smaller networking stack.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: covoar SIGKILL Investigation

2018-08-22 Thread Vijay Kumar Banerjee 
I will send the attachment offlist as it's too big for the list.
On Wed, 22 Aug 2018 at 21:07, Vijay Kumar Banerjee 
wrote:

> The coverage for whole testsuite completed successfully,
> I have attached the zip file here and also included the js and css files
> in it.
>
> coverage didn't complete for the following symbol-set libraries and was
> returning,
> covoar error 10
>
> * libsapi.a
> * libposix.a
> * librfs.a
> * libcsupport.a
> * libdevnull.a
> * libblock.a
>
>
> On Wed, 22 Aug 2018 at 10:22, Chris Johns  wrote:
>
>> On 22/08/2018 14:41, Joel Sherrill wrote:
>> > On Tue, Aug 21, 2018, 10:26 PM Chris Johns > > > wrote:
>> >
>> > On 22/08/2018 09:29, Joel Sherrill wrote:
>> > > On Tue, Aug 21, 2018, 4:05 PM Vijay Kumar Banerjee
>> > mailto:vijaykumar9...@gmail.com>
>> > > >>
>> wrote:
>> > > On Wed, 22 Aug 2018 at 01:55, Joel Sherrill > > 
>> > > >> wrote:
>> > >
>> > > How long is covoar taking for the entire set?
>> > >
>> > > It works great. this is what `time` says
>> > > 
>> > > real17m49.887s
>> > > user14m25.620s
>> > > sys0m37.847s
>> > > 
>> > >
>> > > What speed and type of processor do you have?
>> > >
>> >
>> > The program is single threaded so the preprocessing of each
>> executable is
>> > sequential. Memory usage is reasonable so there is no swapping.
>> >
>> > Running covoar from the command line on a box with:
>> >
>> >  hw.machine: amd64
>> >  hw.model: Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz
>> >  hw.ncpu: 16
>> >  hw.machine_arch: amd64
>> >
>> > plus 32G of memory has a time of:
>> >
>> >   366.32 real   324.97 user41.33 sys
>> >
>> > The approximate time break down is:
>> >
>> >  ELF/DWARF loading  : 110s (1m50s)
>> >  Objdump: 176s (2m56s)
>> >  Processing :  80s (1m20s)
>> >
>> >
>> > I don't mind this execution time for the near future. It is far from
>> obscene
>> > after building and running 600 tests.
>>
>> Yeah, there are other things we need to do first.
>>
>> > The DWARF loading is not optimised and I load all source line to
>> address maps
>> > and all functions rather that selectively scanning for specific
>> names at the
>> > DWARF level. It is not clear to me scanning would be better or
>> faster.
>> >
>> > I doubt it is worth the effort. There should be few symbols in an exe
>> we don't
>> > care about. Especially once we start to worry about libc and libm.
>>
>> Yeah, this is what I thought at the start.
>>
>> > My hope
>> > is moving to Capstone would help lower or remove the objdump
>> overhead. Then
>> > there is threading for the loading.
>> >
>> > > I don't recall it taking near this long in the past. I used to
>> run it as
>> > part of
>> > > development.
>> >
>> > The objdump processing is simpler than before so I suspect the time
>> would have
>> > been at least 4 minutes.
>> >
>> > > But we may have more tests and the code has changed.
>> >
>> > I think having more tests is the dominant factor.
>> >
>> > > Reading dwarf
>> > > with the file open/closes, etc just may be more expensive than
>> parsing the
>> > text
>> > > files.
>> >
>> > The reading DWARF is a cost and at the moment it is not optimised
>> but it is only
>> > a cost because we still parse the objdump data. I think opening and
>> closing
>> > files is not a factor.
>> >
>> > The parsing the objdump is the largest component of time. Maybe
>> using Capstone
>> > with the ELF files will help.
>> >
>> > > But it is more accurate and lays the groundwork.for more types of
>> analysis.
>> >
>> > Yes and think this is important.
>> >
>> > +1
>> >
>> > > Eventually we will have to profile this code. Whatever is costly
>> is done for
>> > > each exe so there is a multiplier.
>> > >
>> > > I suspect this code would parallelize reading info from the exes
>> fairly well.
>> >
>> > Agreed.
>> >
>> > Might be a good case for C++11 threads if one of the thread container
>> classes is
>> > a nice pool.
>>
>> Good idea. I think we need to look at some of the global object pointers
>> before
>> we head down this path.
>>
>> > And we might have some locking to account for in core data structures.
>> Are STL
>> > container instances thread safe?
>>
>> We need to manage all locking.
>>
>> > But an addition after feature stable relative to old output plus
>> Capstone.
>>
>> Agreed.
>>
>> > > Merging the info and generating the reports not well due to data
>> contention.
>> >
>> > Yes.
>> >
>> > > But optimizing too early and the wrong way is not smart.
>> >
>> > Yes. We need Capstone to be added before this can

Aligned operations mismatch

2018-08-22 Thread Mikhail Svetkin 
Hi all,

I have found a problem with assembler code generation in network stack on
ARM processor (aligment fault).

I am using:
arm-rtems5-gcc (GCC) 7.2.0 20170814 (RTEMS 5, RSB
a6d011e028a0776cedf0823940eb882e917a44e5, Newlib 2.5.0.20170922)

The compiler generates invalid instruction 'ldmia' here (
https://git.rtems.org/rtems/tree/cpukit/libnetworking/netinet/udp_usrreq.c#n160
).

The instruction does not support unaligned accesses.

Also i have found the bug fix in FreeBSD repository (
https://github.com/freebsd/freebsd/commit/6cc0e8d2a0b583db5707f811d4ebfbe1ad05e628
)

I tried their solution and it works.

Should I create a ticket for that?

Best regards,
Mikhail
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Some problems with the libbsd update

2018-08-22 Thread Sebastian Huber 

On 22/08/18 14:06, Joel Sherrill wrote:



On Wed, Aug 22, 2018, 6:47 AM Sebastian Huber 
> wrote:


On 22/08/18 13:44, Joel Sherrill wrote:
>
>
> On Wed, Aug 22, 2018, 4:51 AM Sebastian Huber
> mailto:sebastian.hu...@embedded-brains.de>
> >> wrote:
>
>     On 22/08/18 09:50, Sebastian Huber wrote:
>     > To support everything in RTEMS is a lot of work, so I have
to make
>     > some trade-offs. The implementation of this API must be as
>     efficient
>     > as possible since it is used in the critical paths of the
network
>     > stack. I will try to use a single global epoch and
thread-specific
>     > records as suggested by Matthew Macy to avoid the need for
>     > per-processor data structures and the thread pinning. One key
>     issue is
>     > that epoch records must not be destroyed:
>     >
>     > https://www.mankier.com/3/ck_epoch_register
>     >
>     > The consequence of this is that unlimited thread objects may
>     lead to
>     > undefined behaviour with this implementation approach. Also
>     > thread-local storage cannot be used since it is reinitialized
>     once a
>     > thread restarted or reused. The epoch record must be
included in
>     the
>     > Thread_Control and must not be touched by
_Thread_Initialize().
>     This
>     > means I have to move the API and its implementation along
with the
>     > Concurrency Kit to RTEMS.
>
>     Ok, there is also an
>
> http://www.concurrencykit.org/doc/ck_epoch_unregister.html
>
>     and
>
> http://www.concurrencykit.org/doc/ck_epoch_recycle.html
>
>     This allows a localized implementation in libbsd.
>
>     Due to performance reasons this requires the use of thread-local
>     storage. Any objections to make thread-local storage a hard
>     requirement
>     for libbsd support?
>
>
> Not particularly but there should be an effort to identify which
> targets do not have TLS support yet. Other than sparc, arm, powerpc
> and i386, I don't know the status. Sounds like a series of tickets.

TLS is also supported on m68k and riscv. Are the other targets
maintained at all?


Level varies. MIPS is used by Hesham for the CHERI project.


Ok, but is libbsd used here?



I tried to make a sweep to identify the method used by each 
architecture for TLS support and wasn't very successful. If it turns 
out they call a C method for get tls, then it is easy. Do you know how 
to easily cipher that out if the GCC source?


And unless there is a GCC internal flag to throw to change it, the 
MIPS uses a specific undefined instruction and you would have to 
implement get TLS in the exception handler.


Is this really an issue for the up to date MIPS processors?



It really is necessary to know how the other architectures implement 
it. Some may turn out to be easy. Others like Epiphany and new may 
never matter.


If the niche architectures don't use libbsd (which I guess is the case), 
then there is no issue at all.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Some problems with the libbsd update

2018-08-22 Thread Sebastian Huber 

On 22/08/18 13:44, Joel Sherrill wrote:



On Wed, Aug 22, 2018, 4:51 AM Sebastian Huber 
> wrote:


On 22/08/18 09:50, Sebastian Huber wrote:
> To support everything in RTEMS is a lot of work, so I have to make
> some trade-offs. The implementation of this API must be as
efficient
> as possible since it is used in the critical paths of the network
> stack. I will try to use a single global epoch and thread-specific
> records as suggested by Matthew Macy to avoid the need for
> per-processor data structures and the thread pinning. One key
issue is
> that epoch records must not be destroyed:
>
> https://www.mankier.com/3/ck_epoch_register
>
> The consequence of this is that unlimited thread objects may
lead to
> undefined behaviour with this implementation approach. Also
> thread-local storage cannot be used since it is reinitialized
once a
> thread restarted or reused. The epoch record must be included in
the
> Thread_Control and must not be touched by _Thread_Initialize().
This
> means I have to move the API and its implementation along with the
> Concurrency Kit to RTEMS.

Ok, there is also an

http://www.concurrencykit.org/doc/ck_epoch_unregister.html

and

http://www.concurrencykit.org/doc/ck_epoch_recycle.html

This allows a localized implementation in libbsd.

Due to performance reasons this requires the use of thread-local
storage. Any objections to make thread-local storage a hard
requirement
for libbsd support?


Not particularly but there should be an effort to identify which 
targets do not have TLS support yet. Other than sparc, arm, powerpc 
and i386, I don't know the status. Sounds like a series of tickets.


TLS is also supported on m68k and riscv. Are the other targets 
maintained at all?


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Some problems with the libbsd update

2018-08-22 Thread Joel Sherrill 
On Wed, Aug 22, 2018, 4:51 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 22/08/18 09:50, Sebastian Huber wrote:
> > To support everything in RTEMS is a lot of work, so I have to make
> > some trade-offs. The implementation of this API must be as efficient
> > as possible since it is used in the critical paths of the network
> > stack. I will try to use a single global epoch and thread-specific
> > records as suggested by Matthew Macy to avoid the need for
> > per-processor data structures and the thread pinning. One key issue is
> > that epoch records must not be destroyed:
> >
> > https://www.mankier.com/3/ck_epoch_register
> >
> > The consequence of this is that unlimited thread objects may lead to
> > undefined behaviour with this implementation approach. Also
> > thread-local storage cannot be used since it is reinitialized once a
> > thread restarted or reused. The epoch record must be included in the
> > Thread_Control and must not be touched by _Thread_Initialize(). This
> > means I have to move the API and its implementation along with the
> > Concurrency Kit to RTEMS.
>
> Ok, there is also an
>
> http://www.concurrencykit.org/doc/ck_epoch_unregister.html
>
> and
>
> http://www.concurrencykit.org/doc/ck_epoch_recycle.html
>
> This allows a localized implementation in libbsd.
>
> Due to performance reasons this requires the use of thread-local
> storage. Any objections to make thread-local storage a hard requirement
> for libbsd support?
>

Not particularly but there should be an effort to identify which targets do
not have TLS support yet. Other than sparc, arm, powerpc and i386, I don't
know the status. Sounds like a series of tickets.

Certainly seems like the mist straightforward approach to solving the
problem. But it requires some work on TLS which was needed anyway.

>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Some problems with the libbsd update

2018-08-22 Thread Sebastian Huber 

On 22/08/18 09:50, Sebastian Huber wrote:
To support everything in RTEMS is a lot of work, so I have to make 
some trade-offs. The implementation of this API must be as efficient 
as possible since it is used in the critical paths of the network 
stack. I will try to use a single global epoch and thread-specific 
records as suggested by Matthew Macy to avoid the need for 
per-processor data structures and the thread pinning. One key issue is 
that epoch records must not be destroyed:


https://www.mankier.com/3/ck_epoch_register

The consequence of this is that unlimited thread objects may lead to 
undefined behaviour with this implementation approach. Also 
thread-local storage cannot be used since it is reinitialized once a 
thread restarted or reused. The epoch record must be included in the 
Thread_Control and must not be touched by _Thread_Initialize(). This 
means I have to move the API and its implementation along with the 
Concurrency Kit to RTEMS. 


Ok, there is also an

http://www.concurrencykit.org/doc/ck_epoch_unregister.html

and

http://www.concurrencykit.org/doc/ck_epoch_recycle.html

This allows a localized implementation in libbsd.

Due to performance reasons this requires the use of thread-local 
storage. Any objections to make thread-local storage a hard requirement 
for libbsd support?


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Some problems with the libbsd update

2018-08-22 Thread Sebastian Huber 

Hello,

I work currently on an update of the libbsd to the latest FreeBSD head 
(see also https://devel.rtems.org/ticket/3472). I was a quite smooth 
process until May 2018. FreeBSD seems to receive a significant amount of 
funding to perform better on NUMA systems. They started to use lock-free 
data structures in the kernel and included the Concurrency Kit in the 
base system:


https://github.com/freebsd/freebsd/tree/master/sys/contrib/ck

The weak point of lock-free data structures is the memory reclamation. 
FreeBSD introduced an epoch memory reclamation API:


https://github.com/freebsd/freebsd/blob/master/share/man/man9/epoch.9

It is now used for basic synchronization in the network stack and hard 
to avoid. The Concurrency Kit and the epoch memory reclamation API are 
interesting features for RTEMS as well. The FreeBSD implementation needs 
a thread pinning feature which is hard to implement in RTEMS. It turned 
out that this is only used as an optimization, see also:


https://lists.freebsd.org/pipermail/freebsd-hackers/2018-August/053165.html

To support everything in RTEMS is a lot of work, so I have to make some 
trade-offs. The implementation of this API must be as efficient as 
possible since it is used in the critical paths of the network stack. I 
will try to use a single global epoch and thread-specific records as 
suggested by Matthew Macy to avoid the need for per-processor data 
structures and the thread pinning. One key issue is that epoch records 
must not be destroyed:


https://www.mankier.com/3/ck_epoch_register

The consequence of this is that unlimited thread objects may lead to 
undefined behaviour with this implementation approach. Also thread-local 
storage cannot be used since it is reinitialized once a thread restarted 
or reused. The epoch record must be included in the Thread_Control and 
must not be touched by _Thread_Initialize(). This means I have to move 
the API and its implementation along with the Concurrency Kit to RTEMS.


Alternatively, I could try to implement the thread pinning feature. I am 
not sure if it is possible at all. It will definitely not work well 
together with mutex obtain timeouts.


Adding support for general purpose per-processor data structures would 
be quite easy. We just have to collect all per-processor data in a 
linker section and duplicate the section content for each secondary 
processor. Then use the _Per_CPU_Information[] to get a pointer to the 
corresponding memory area.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel