summaryrefslogtreecommitdiff
path: root/btt
diff options
context:
space:
mode:
authorAlan D. Brunelle <alan.brunelle@hp.com>2009-02-09 15:11:49 -0500
committerAlan D. Brunelle <alan.brunelle@hp.com>2009-02-09 15:11:49 -0500
commit3fe0b570b01622e329b9c999ebf867b1f1cb2e20 (patch)
treea08a6ac913597c817c7f35226ed34aecf7ed3c34 /btt
parent99bb5ebc255618e4af913d2e5f1bf268af552bdf (diff)
downloadblktrace-3fe0b570b01622e329b9c999ebf867b1f1cb2e20.tar.gz
blktrace-3fe0b570b01622e329b9c999ebf867b1f1cb2e20.tar.bz2
Rewrote blktrace to have a single thread per CPU
Massive changes: mostly around the notion of having much fewer threads (instead of N(devs) X N(cpus) threads, we'll have just N(cpus)). This is very important for larger systems (with lots of devices to trace). A lot of the code was stolen from the original blktrace code, major changes include: o On the client side we only have a single thread per client CPU. Each thread will then open all device files for that CPU, and use poll to determine which file needs processing. o For network client mode w/ sendfile, this means that a single socket will carry all data to the remote network server. The network server side will then distribute its reads off that one socket onto different trace files. o For network client mode w/out sendfile, we fall back to doing things like piped mode: keep buffers of tracers read in, and then the main thread will issue these on sockets to the server. In this case, the main thread will still have a single socket per CPU. o For networked mode we added an OPEN concept on the client side: as soon as the connection to the server is set up, a "header" is sent signifying that this connection will handle a <cpu, device> tuple. For each socket opened on the client side, it will send a header per device being managed. The server side will handle utilize opens to set up appropriate data structures to handle incoming data streams. o For both the OPEN and CLOSE headers the server will acknowledge with a short write back to the client. This allows the client & server sides to gracefully close socket connections. o I also re-did the resource limitiation issue a bit differently: for open calls (including socket) or for memory map/lock calls I have provided a wrapper function that will try to increase specific limits as needed. The previous method (attempting to do it at the beginning of the run) fails for network server mode - you don't know at initialization how many devices and CPUs will be handled. o The standard output is slightly different in a few places, if this is a problem w/ compatibility we can work to rectify that. The command line argument handling is identical though. o Using code stolen from Linux to manipulate doubly-linked lists. I've found that this makes the code easier to read/write (but may be a bit of overkill here...) o The code passes valgrind quite well (at least for my tests so far). The only nit has to do with inet_ntoa - but that is out of our control. Thanks to Stefan Raspl <raspl@linux.vnet.ibm.com> for testing and finding some issues and for providing suggestions. Signed-off-by: Alan D. Brunelle <alan.brunelle@hp.com>
Diffstat (limited to 'btt')
-rw-r--r--btt/list.h23
1 files changed, 23 insertions, 0 deletions
diff --git a/btt/list.h b/btt/list.h
index 363c888..71c4a65 100644
--- a/btt/list.h
+++ b/btt/list.h
@@ -213,4 +213,27 @@ static inline void list_splice(struct list_head *list, struct list_head *head)
__list_splice(list, head);
}
+/**
+ * list_replace - replace old entry by new one
+ * @old : the element to be replaced
+ * @new : the new element to insert
+ *
+ * If @old was empty, it will be overwritten.
+ */
+static inline void list_replace(struct list_head *old,
+ struct list_head *new)
+{
+ new->next = old->next;
+ new->next->prev = new;
+ new->prev = old->prev;
+ new->prev->next = new;
+}
+
+static inline void list_replace_init(struct list_head *old,
+ struct list_head *new)
+{
+ list_replace(old, new);
+ INIT_LIST_HEAD(old);
+}
+
#endif