Yan <[EMAIL PROTECTED]> wrote: > I am currently writing my first kernel module to extract data from > the kernel and bring it into user-space. As I understand, FreeBSD > only loads pages of the text segment that it is about to use by > registering its handler for page faults, and bringing in more pages > from the binary as needed. I want to track this progress, and report > the amount of pages it brought in on process exit. > > The current idea I have and the path I'm following is as follows: > I register a callback in my module using EVENTHANDLER_REGISTER, > using 'process_exit' name. That gives me the proc structure on exit, > I then try to find the information I need using the p_vmspace member, > and try using vm_tsize for the number of pages. But this is the > number of pages in the virtual address space of the text segment, > which does not correlate to how many pages were actually brought > in. > > For the context of this, I am trying to write a tiny utility, that > watches the execution of a process, and tracks how many pages were > actually used during its execution. It passes that knowledge to a > hopefully-to-be-written user-space utility that generates a new > binary using only those pages for the text segment. (If an execution > was to go outside that, a seg fault is okay.) > > Any help is appreciated.
The problem with that is the fact that text pages are not "owned" by a process. If you run the same binary several times, the pages will be brought into memory only once. So if you're running a webserver with hundreds of httpd processes, the text pages of httpd are brought into memory only once. Unless, of course, some of them (or even all of them) had to be re-used during a low-memory situation, so they have to be brought in again. Note that text pages are _not_ paged out to swap space, because that would be just a waste since. Instead they are simply discarded, because they can be paged in from the binary again. So, if you really need to assign page-ins to a certain process, you must make sure that the binary in question was never executed before (since last reboot), and make sure that it is not executed again until the first process terminates. Also note that you might easily miss code paths that are not executed during one run, but required during another run, so you might not get all pages that are necessary to run the binary under all circumstances. I also think that the pager will bring multiple pages into memory at once, as an optimization because doing for every single page on demand is inefficient, especially on large binaries. (I'm not 100% sure how that works, though. Someone will certainly correct me if necessary.) By the way, /usr/bin/time is very useful with the option -l to display pageing activity during execution of a process. Here's just an example with running lynx two times after another (I hadn't used it before since last reboot, but all the libraries had already been used): $ /usr/bin/time -l lynx -dump {some URL} >/dev/null 259 page reclaims 37 page faults 10 block input operations $ /usr/bin/time -l lynx -dump {some URL} >/dev/null 243 page reclaims 0 page faults 0 block input operations Note that the size of the binary is about 1 MB, which is about 250 pages: -r-xr-xr-x 1 root wheel 1086480 Jul 20 2005 lynx Not all of those pages are text pages, though, of course. By the way: Even if you manage to find out which pages are actually used by a binary, it is probably non-trivial to map that information back to parts of the binary file, let alone to build a binary that contains only those parts. You'll have to fight with the run-time linker. Uhm ... The more I think about the whole thing, the more potential problems come to my mind, so I better stop now. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing." -- Mother Teresa _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"