Date: Mon, 10 Mar 2003 09:33:13 -0800 (PST) From: Nate Lawson <nate@root.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/sys devicestat.h Message-ID: <Pine.BSF.4.21.0303100924470.93706-100000@root.org> In-Reply-To: <78207.1047196679@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
/* Single sequence var ensures data is consistent */
do {
memcpy(local_stat, src_stat, sizeof(struct devicestat));
} while (local_stat->seq != src_stat->seq);
Also, why was this implemented as mmap() and not read()? If it was
read(), the kernel could take care of the messiness of the sequenceX and
the user could just use the data.
-Nate
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?Pine.BSF.4.21.0303100924470.93706-100000>