2014-04-28 (월), 12:01 +0200, Jiri Olsa: > On Sun, Apr 27, 2014 at 11:36:35PM +0900, Namhyung Kim wrote: > > 2014-04-17 (목), 19:39 +0200, Jiri Olsa: > > > Keeping the data file description open for the whole life > > > of the dso object. > > > > I suspect there might be an issue for reporting very large data file > > with this approach - like open file limit? > > I've got as high as ~200 openned file descriptors for > ~2GB data of system wide monitoring > > but right that could be an issue.. I wonder we could > workaround this somehow, because the speed up is quite > noticable > > how about we monitor number of openned dso file descriptor > and once we cross this we close some portion of them > > or something along those lines ;-)
Yeah, we'll need some way to control those eventually. > > > > > > > [SNIP] > > > @@ -168,8 +174,8 @@ int dso__data_fd(struct dso *dso, struct machine > > > *machine) > > > }; > > > int i = 0; > > > > > > - if (dso->binary_type != DSO_BINARY_TYPE__NOT_FOUND) > > > - return open_dso(dso, machine); > > > > Why did you remove this line? > > that code reopens already openned (and closed) file.. > instead I return (not closed) descriptor from previous open But it'll overwrite the dso->binary_type then. What about this? if (dso->data_fd >= 0) return dso->data_fd; if (dso->binary_type != DSO_BINARY_TYPE__NOT_FOUND) { dso->data_fd = open_dso(dso, machine); return dso->data_fd; } Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/