Messages in this thread | | | Date | Thu, 29 Jun 2006 15:43:41 -0400 | From | Shailabh Nagar <> | Subject | Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats |
| |
Andrew Morton wrote:
>On Thu, 29 Jun 2006 15:10:31 -0400 >Shailabh Nagar <nagar@watson.ibm.com> wrote: > > > >>>I agree, and I'm viewing this as blocking the taskstats merge. Because if >>>this _is_ a problem then it's a big one because fixing it will be >>>intrusive, and might well involve userspace-visible changes. >>> >>> >>> >>> >>First off, just a reminder that this is inherently a netlink flow >>control issue...which was being exacerbated >>earlier by taskstats decision to send per-tgid data (no longer the case). >> >>But I'd like to know whats our target here ? How many messages per >>second do we want to be able to be sent >>and received without risking any loss of data ? Netlink will lose >>messages at a high enough rate so the design point >>will need to be known a bit. >> >>For statistics type usage of the genetlink/netlink, I would have thought >>that userspace, provided it is reliably informed >>about the loss of data through ENOBUFS, could take measures to just >>account for the missing data and carry on ? >> >> > >Could be so. But we need to understand how significant the impact of this >will be in practice. > >We could find, once this is deployed is real production environments on >large machines that the data loss is sufficiently common and sufficiently >serious that the feature needs a lot of rework. > >Now there's always a risk of that sort of thing happening with all >features, but it's usually not this evident so early in the development >process. We need to get a better understanding of the risk before >proceeding too far. > >
>And there's always a 100% reliable fix for this: throttling. Make the >sender of the messages block until the consumer can catch up. > Is blocking exits an option ?
> In some >situations, that is what people will want to be able to do. I suspect a >good implementation would be to run a collection daemon on each CPU and >make the delivery be cpu-local. That's sounding more like relayfs than >netlink. > > Yup...the per-cpu, high speed requirements are up relayfs' alley, unless Jamal or netlink folks are planning something (or can shed light on) how large flows can be managed over netlink. I suspect this discussion has happened before :-)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |