Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

ARM support #277

Closed
Max-Might opened this Issue · 13 comments

7 participants

@Max-Might

Hi.

Has anyone tried to compile and run RethinkDB on an ARM hardware?
RaspberryPI probably?

@jdoliner

I have. We have some inlined assembly that needs to be ported over to arm and I assume some system calls that will need to change. This is something of low corporate priority but medium personal priority to me.

@coffeemug coffeemug referenced this issue
Closed

ARM support #1309

@paulpcx

Keep up the good work RethinkDB team. Really enjoyed using rethinkdb.

Would love to be able to run RethinkDB on RaspberryPI. +++++

@davidthomas426

I've started trying to implement this, but I've hit a bit of a snag. In debug mode, the watchdog code uses rdtsc as a high-resolution timer. This is not portable, and in particular, there is no real equivalent on ARM. My plan for now is to fake it by attempting to measure nanoseconds instead of cycles, pretending that they are the same thing, using clock_gettime. Would anyone like to chime in on this?

@danielmewes
Owner

@davidthomas426 We are probably going to get rid of the watchdog anyway. Independent of that, you could just disable it under ARM through some #ifndefs. The watchdog is just a debug tool for identifying performance issues, nothing of importance for RethinkDB to work.

@coffeemug
Owner

@davidthomas426 -- I just want to chime in and say that what you're doing is awesome! Please keep us posted on your progress. Also, if you fill out the form here http://www.rethinkdb.com/community/shirts-for-stories/ we'd love to send you some goodies :)

@danielmewes
Owner

Also, if that is less of a hassle than having to put #ifndefs everywhere: Using clock_gettime() as a replacement in the watchdog sounds perfectly fine to me.

@davidthomas426

I got it working without compiler optimization, but with optimization I'm having problems when a coroutine migrates to another thread and then accesses thread-local storage. For example, suppose a coroutine is on thread 0, and wants to move to thread 1. The optimizer causes the coroutine to cache the thread pointer for thread 0 in a register, then move to thread 1, then use the cached thread pointer, which is now incorrect.

A Google search revealed other people discussing this problem, which is not just for ARM:

@coffeemug
Owner

David, that's awesome! Are you planning to submit a pull request? I can't promise we'll merge it in (because of added maintenance burden), but we are looking forward to getting Rethink to run on a Raspberry Pi :)

@davidthomas426

It only works when compiled without optimization, so I didn't want to submit a pull request yet. With optimization, the first thread-local access after a coroutine migrates to a different thread results in a segfault (because it's looking at the wrong thread's version of the thread-local). The problem is, I'm not sure how to fix this problem (well, short of something crazy...like storing a global array for each thread-local variable storing the addresses of the variable on each thread, and using the gettid syscall to find out what thread I'm on every time I want to access TLS).

I've posted a question on stackoverflow about it at http://stackoverflow.com/questions/19811474/how-do-i-force-g-on-linux-to-update-the-thread-pointer-for-tls-when-a-corout

@coffeemug
Owner

@davidthomas426 -- I know there is still an optimization issue, we just wanted an ARM branch to play with in the meantime :) Also, I just commented on stack overflow with some ideas on how to get this fixed.

I sent you a separate e-mail a day or so ago (to the e-mail on your github profile). If you didn't get it, could you shoot me an e-mail to slava@rethinkdb.com ?

@danielmewes
Owner

@davidthomas426 For your information: With newer versions of GCC (4.8), we are now hitting the same issue with compiler optimizations on i386 as well. See #1731 (comment)

I'm sure we will find a solution to this somehow.

@AtnNn AtnNn modified the milestone: 1.12, backlog
@AtnNn
Collaborator

Closed by #1625.

@AtnNn AtnNn closed this
@AtnNn AtnNn modified the milestone: duplicate, 1.12
@coffeemug
Owner

Awesome! :+1:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.