coprthr_tls_sbrk and coprthr_tls_brk

Moderator: dar

coprthr_tls_sbrk and coprthr_tls_brk

Postby nickoppen » Fri Apr 15, 2016 4:57 am

Hi JAR,

Could you give me a quick overview as to how coprthr_tls_sbrk and coprthr_tls_brk work please? It seems like the coprthr_tls_sbrk(n) call allocates memory on the core and then coprthr_tls_sbrk(0) frees it again both returning a pointer. And coprthr_tls_brk(0) just frees it and does not return a pointer. Is that right?

Is it necessary to call void* memfree = coprthr_tls_sbrk(0) before calling coprthr_tls_sbrk(n) and then call coprthr_tls_brk(memfree) when everything is done?

nick
Sharing is what makes the internet Great!
User avatar
nickoppen
 
Posts: 266
Joined: Mon Dec 17, 2012 3:21 am
Location: Sydney NSW, Australia

Re: coprthr_tls_sbrk and coprthr_tls_brk

Postby jar » Fri Apr 15, 2016 5:20 am

They're modeled after the Unix brk/sbrk.

The 32KB of memory in an Epiphany-III core looks something like this:



IVT
Epiphany configuration
User program
Free space


When you use brk/sbrk, you are manipulating the free space heap. You can think of it a bit like a malloc, but there is no memory virtualization. The pointer that is returned is a physical address rather than a virtual address that a malloc may give you.

The first call void* memfree = coprthr_tls_sbrk(0) returns the pointer to the beginning of the free space. The internal pointer that keeps track of the boundary of free space is incremented by 0, and the original value is returned. When you give a size N to sbrk(N), you are getting the current pointer value of free space and the internal value is incremented by N. Finally, when you call brk(memfree), you are resetting the internal free space pointer back to the original value that it had when you first called sbrk(0).

It's very simple. There isn't much happening inside the routines. They are lower level than a malloc. You can't malloc space on the cores like you traditionally would on the host.

If you don't intend to release memory before ending your program, you do not need the initial sbrk(0) or the final brk(memfree). It will still work, but is poor practice like not freeing malloc'd memory.

If you want to know more about what's coming down the pike, read these two pre-print manuscripts below. They were just uploaded in the last few hours.

Implementing OpenSHMEM for the Adapteva Epiphany RISC Array Processor
Advances in Run-Time Performance and Interoperability for the Adapteva Epiphany Coprocessor
User avatar
jar
 
Posts: 295
Joined: Mon Dec 17, 2012 3:27 am

Re: coprthr_tls_sbrk and coprthr_tls_brk

Postby nickoppen » Fri Apr 15, 2016 7:14 am

Awesome. Thanks for your answer.
Sharing is what makes the internet Great!
User avatar
nickoppen
 
Posts: 266
Joined: Mon Dec 17, 2012 3:21 am
Location: Sydney NSW, Australia


Return to OpenCL

Who is online

Users browsing this forum: No registered users and 1 guest

cron