Date: Mon, 10 Mar 2003 19:04:07 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Nate Lawson <nate@root.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/sys devicestat.h Message-ID: <2856.1047319447@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 10 Mar 2003 09:33:13 PST." <Pine.BSF.4.21.0303100924470.93706-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.21.0303100924470.93706-100000@root.org>, Nate Lawson wri tes: >On Sun, 9 Mar 2003, Poul-Henning Kamp wrote: >> In message <Pine.BSF.4.21.0303082347200.90870-100000@root.org>, Nate Lawson wri >> tes: >> >> >> Yes, these structures will be mmap'ed from kernel to userland and user >> >> land will (likely) memcpy() them to private storage as snapshot'ing. >> >> To be able to tell if you have an atomic snapshot, the two counters >> >> must be identical. >> > >> >How about a mtx covering the structure and a read from the device returns >> >the structure under lock? >> >> The goal is to avoid locking in the kernel and put the overhead in >> userland. Remember, most of the time nobody cares about the statistics >> so they should be cheap. > >I'm unsure why two counters are required. One counter at the start of the >structure is sufficient if you 1. memcpy the structure and then 2. re-read >the counter int to make sure it is the same as the one covered by the >memcpy. (This assumes memcpy can read an int atomically which should be >true). Hmm, a volatile keyword may be necessary for the user-visible >struct. Think two cpu system. One cpu doing the memcpy in userland while the other is updating the data structure in the kernel. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-src" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2856.1047319447>