- Apr 10, 2013
-
-
Nadav Har'El authored
When out of memory in alloc_page() or malloc_large(), we used to produce mysterious assertion failures or aborts. Now print a more user-friendly "out of memory" error (and abort).
-
Nadav Har'El authored
To run the debug build, instead of "scripts/run.sh debug", use "scripts/run -d".
-
Dor Laor authored
Also fix the numbering.
-
- Apr 09, 2013
-
-
Christoph Hellwig authored
-
Avi Kivity authored
Tracepoint command line support.
-
Avi Kivity authored
Enable via command line.
-
Avi Kivity authored
usage: --trace=a,b,c,*foo* --trace=bar java.so ... Will match on tracepoint names.
-
Avi Kivity authored
e.g. enable_tracepoint("*function*");
-
Nadav Har'El authored
We used to have libz in bootfs.manifest, and now that it was removed, it needs to be put in usr.manifest... It is needed by Java to load the compressed jar.
-
Nadav Har'El authored
"osv info threads" used to show the switch_to() function for all non-running threads. Now, it attempts to skip "obvious" functions until finding a less obvious caller which initiated the final thread switch. Currently, the mechanism to define obvious functions is pretty crude - it just considers all functions in arch-switch.hh, sched.cc, sched.hh or mutex.hh, to be obvious, avoiding showing things like switch_to(), schedule(), wait_until(). In the future we can refine this definition. In my opinion it would be best if we could decide on one file (or a small set of files) which contain all these generic switching/waiting functions and we'll simply avoid showing anything from these files in "osv info threads".
-
Nadav Har'El authored
Since commit 5384840a which changed the way we remember a non-running thread's rip and rbp, "osv info threads" was broken and showed question marks for all non-running threads. Now it's fixed but always shows sched::thread::switch_to() as non-running threads indeed called this function last.
-
Avi Kivity authored
Useful for command line enabling/disabling tracepoints by name.
-
Christoph Hellwig authored
-
Avi Kivity authored
Initial tracepoint work. Still some optimization left to do, but the basic framework is ready. Declare: #include "osv/trace.hh" tracepoint<int, long> trace_some_event("some_event", "p1=%d p2=%d"); Use: trace_some_event(10, 20); View: (gdb) osv trace
-
Avi Kivity authored
-
Avi Kivity authored
-
Avi Kivity authored
Make tracing usable by writing the log to memory rather than the console. We reuse the log previously used by function tracing (which is switched to tracepoints, so that common machinery is used).
-
Avi Kivity authored
Instrumenting functions used in the trace machinery causes infinite recursion.
-
Avi Kivity authored
They're trivial and deserve inlining.
-
- Apr 08, 2013
-
-
Avi Kivity authored
Strangely, the compiler is able to remove the test code (including the assert) entirely, as it is able to deduce it passed at compile time.
-
Avi Kivity authored
Use the native alignment for speed.
-
Nadav Har'El authored
All child threads start running on the CPU which started them, until migrated later in load_balancer(). Threads with pinned=true are not migrated. Unfortunately, we forgot to initialize the pinned field (POD fields are not initialized in C++) - so all threads started with random, usually nonzero, "pinned" value and as a result all threads remained on CPU 0! Now thread migration works as expected.
-
Avi Kivity authored
This allows the log to refer to the tracepoint and thus also the type signature.
-
Avi Kivity authored
This allows the trace log to refer to the tracepoint.
-
Nadav Har'El authored
wait_until made recursive use of wait_guard: It held one around the code calling wait(), but while still holding it also called mutex_lock() which also uses a wait_guard internally. This sort of recursive use of wait_guard is theoretically supported, but messy to debug, so I now changed the code a bit so only one of them are held at a time (the lock() is outside wait_guard).
-
Nadav Har'El authored
In some cases, stop_wait() forgot to call preempt_enable(), leaving the preemption of this thread disabled, and causing CPU-heavy threads to continue running for a long time without other threads (or even load_balance()) getting a chance to run.
-
Avi Kivity authored
-
Avi Kivity authored
This can be used to recover the data types from a raw buffer (i.e. from a debugger). We use the Python struct module encoding (I=u32, etc.).
-
Avi Kivity authored
-
Avi Kivity authored
Two styles are supported, a simple one and a flexible one. To declare and use a simple tracepoint, use: tracepoint<u32, u64, char> trace_my_event("my_event", "%d %x '%s'"); ... void my_function(u32 a0, u64 a1) { trace_my_event(a0, a1, 'x'); } where: u32/u64/char: the types of the parameters to be used in the tracepoint trace_my_event: an identifier (commonly prefixed by trace_) "my_event": how the tracepoint is shown in the logs "%d %x '%s'": printf/boost::format style format string (auto deduces argument types) a0, a1, 'x': runtime arguments to be traced The flexible style allows different type lists used in the tracepoint function, and in storing. This allows having the tracepoint snapshot fields from some object. You will need to supply a function to convert from the runtime types to the storage types: std::tuple<u32, u64, char> snapshot_my_object(my_object& obj) { return std::make_tuple(obj.field1, obj.field2, obj.field3); } tracepointv<storage_args<u32, u64, char>, runtime_args<my_object&>, snapshot_my_object> trace_my_object("my_object", "%d %x '%s'"); void my_function(my_object& obj) { trace_my_object(obj); } Using this style reduces the runtime overhead since 'snapshot_my_object' is only run if tracing is enabled.
-
Nadav Har'El authored
Thread object creation used to leak one page for the FPU state (thanks Avi for spotting this). Fix this (add a destructor which frees the page) and add to the test-suite a test for checking that thread creation doesn't leak memory - and while we're at it, also checked that alloc_page() and malloc() at various sizes do not leak memory.
-
Nadav Har'El authored
We forgot to free the TCB allocated buffer on thread destruction, causing a leak of around 1000 bytes per thread creation. We still have another leak (exactly one page per thread object creation) that I'm trying to find :(
-
- Apr 07, 2013
-
-
Nadav Har'El authored
Thread's destructor calls join(), which used to hang if called before the thread was ever start()ed because it would wait forever for the thread to change its status to terminated. If join() see the thread was never started, return immediately.
-
Guy Zana authored
-
Guy Zana authored
the socket implementation of fo_close() frees the socket structure and that in turn invokes poll_wake() which uses refcounting as it mess with the file structure. the following patch increases the refcount by 1 before calling fo_close() so we avoid entering the free area in fdrop twice.
-
Guy Zana authored
bug fix: a reference is held by fget(), make sure to release a refcount
-
Guy Zana authored
-
Guy Zana authored
-
Guy Zana authored
-
Guy Zana authored
-