On Mon, Apr 28, 2014 at 10:16:34PM +0900, Namhyung Kim wrote: > 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; > }
right, makes sense.. I'll add it with the control code for the number of openned descriptors thanks, jirka -- 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/