Linked by nfeske on Thu 23rd Aug 2012 08:30 UTC
OSNews, Generic OSes The just released version 12.08 of the Genode OS Framework comes with the ability to run Genode-based systems on ARM hardware without an underlying kernel, vastly improves the support for the NOVA hypervisor, and adds device drivers for the OMAP4 SoC. Further functional additions are a FFAT-based file system service, the port of the lighttpd web server, and support for on-target debugging via GDB.
Thread beginning with comment 532016
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Good Progress
by Alfman on Fri 24th Aug 2012 18:00 UTC in reply to "RE: Good Progress"
Alfman
Member since:
2011-01-28

I think there'd be merit in having base-hw on x86 given the widespread availability of off the shelf hardware.. but of course you gotta focus with what matters to you.

System programming jobs have become rare here, I've always thought it would be so much fun to land a job working on an alternative operating system instead of just doing it as a hobby.

So anyway, back on topic, I read this in your release notes:

"We complemented our C runtime with support for the pread, pwrite, readv, and writev functions. The pread and pwrite functions are shortcuts for randomly accessing different parts of a file. Under the hood, the functions are implemented via lseek and read/write. To provide the atomicity of the functions, a lock guard prevents the parallel execution of either or both functions if called concurrently by multiple threads."

You are implementing these functions (pread/pwrite) with two system calls then? Is there one lock per process, per file descriptor, or something else? Is this lock held in the kernel or in user space? It seems to me like such locks could impose a major synchronization bottleneck on SMP architectures, is there a reason you wouldn't just add new syscalls for pread/pwrite?

Reply Parent Score: 2

RE[3]: Good Progress
by nfeske on Fri 24th Aug 2012 19:48 in reply to "RE[2]: Good Progress"
nfeske Member since:
2009-05-27

For running Genode on x86 in general, there is no urgent need to have this architecture covered by base-hw. There are several other kernels among Genode's supported base platforms that support x86 just fine, i.e., NOVA.

Thank you for having taken the time to study the release notes in such detail.

The paragraph you cited refers to the libc. Before the change, the mentioned functions had been mere dummy stubs. Now, they do something meaningful. The lock is locally within the process. The kernel doesn't know anything about the lock nor is it directly involved in handling the actual read/write/lseek operation. Please remember that we are using a microkernel-based architecture where I/O is performed by user-level components rather than the kernel.

Is one lock for pread/pwrite per process a bottleneck? This is a good question, which is quite hard to answer without having a workload that heavily uses these functions from multiple threads. As long as many processes contend for I/O or the workload is generally bounded by I/O, this is not a scalability issue.

For multi-threaded POSIX applications that call those functions concurrently, however, I agree that the lock per process could be replaced by a lock per file descriptor to improve SMP scalability. I couldn't name such an application from the top of my head, though. Do you have an example that would be worthwhile to investigate? We may change the locking once we see this becoming a real issue rather than a speculative one. Until then, it is just nice to have the functional gap in Genode's libc closed without the risk of introducing race conditions.

Reply Parent Score: 2

RE[4]: Good Progress
by Alfman on Sat 25th Aug 2012 14:37 in reply to "RE[3]: Good Progress"
Alfman Member since:
2011-01-28

nfeske,

Like you, I'd have to research it more. But I think an excellent test would be a database engine that doesn't use memory mapped IO. I think mysql is such a database, particularly because 32bit addressing is an unacceptable limitation. Not sure how it works in 64 bit though.

http://doc.51windows.net/mysql/?url=/MySQL/ch07s05.html
"Only compressed MyISAM tables are memory mapped. This is because the 32-bit memory space of 4GB is not large enough for most big tables. When systems with a 64-bit address space become more common, we may add general support for memory mapping."


When you implement a pread in libc, does it look something like this?
(Apologies in advance for the spacing bugs...Thom get that fixed!!)


int pread(...) {
aquire_process_mutex(...);
long long pos = lseek(...);
int ret = read(...);
lseek(pos); // since pread isn't supposed to have side effects
free_mutex(...);
return ret;
}

This makes 3 calls to the file system, do those functions have their own internal mutexes such that each pread/pwrite call will actually invoke 4 total mutex cycles (instead of 1 needed by a native pread function)? That would be alot of sync overhead on SMP systems (IMHO).


Also, I think the following example might be able to break the above atomicity:

void uncertainty() {
char data;
int handle = open(...,O_WRONLY|O_TRUNC);

int pid = fork();

if (pid==0) {
data=1;
pwrite(handle, &data, sizeof(data), 1)
} else {
data=2
pwrite(handle, &data, sizeof(data), 1);
waitpid(pid);
}

}


We would normally expect only 2 possible arbitrary outcomes:

0x00 0x01 # child overwrote parent
0x00 0x02 # parent overwrote child

However due to race conditions on lseek, we might end up with these variances as well.

0x02 0x01
0x01 0x02


Granted this example is contrived. I don't know if there are typical applications that share file descriptors between processes and use pread/pwrite on them?


I brought this up because I really enjoy technical analysis, not because of any particular concern. But if I'm bugging you too much feel free to tell me to sod off ;)

Reply Parent Score: 2