Re: Checksum mismatch -- will transfer entire file
On Mon, 14 Jun 2010 11:43:08 +0700 Victor Sudakov sudakov+free...@sibptus.tomsk.ru wrote: Victor Sudakov wrote: [dd] But to hell with this. I started the topic because I think something is wrong with SVN to CVS export, which upsets cvsup and causes Checksum mismatch errors. Is anybody willing to look at it? I see nobody is ever going to fix this? Cvsup mails me a bunch of Checksum mismatch errors on every run, with a risk of overlooking real errors. How do others deal with this noise? Do you grep cvsup output or what? I just ignore these errors. I've never seen a problem as a result. -- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
GEOM_DEBUG kernel option
I introduce new kernel option GEOM_DEBUG Its enabled on default, but disable it reduce runtime kernel size and slightly improve performance by disabling debug stuff in compile time On my amd64 machine compiling modules without GEOM_DEBUG option reduce size geom_mirror.ko from 130 to 77 kilobytes geom_label.ko from 44.5 to 33 kilobytes http://193.34.20.243/geom.20100611.patch ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
GEOM_DEBUG kernel option
I introduce new kernel option GEOM_DEBUG Its enabled on default, but disable it reduce runtime kernel size and slightly improve perfomance by disabling debug stuff in compile time On my amd64 machine compiling modules without GEOM_DEBUG option reduce size geom_mirror.ko from 130 to 77 kilobytes geom_label.ko from 44.5 to 33 kilobytes http://193.34.20.243/geom.20100611.patch ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RFT Exposing Zone Sleeps
So, after some modifications and guidance from rwatson, alc and others,
I've modified this patch a bit. The end result is that a sleep on slab
alloc counter is displayed with a vmstat -z. This can be used for
diagnostics of low memory situations and has been VERY handy at Yahoo.
I've removed the sysctl to eliminate some heartache, moved the sleep
count into a proper place in the data structure, properly instrumented
the debugger function and returned the #ifdef.
Patch provided against -current. Tested on amd64 and x86
Sean
Index: usr.bin/vmstat/vmstat.c
===
--- usr.bin/vmstat/vmstat.c (revision 209161)
+++ usr.bin/vmstat/vmstat.c (working copy)
@@ -1294,16 +1294,17 @@
memstat_strerror(error));
}
}
- printf(%-20s %8s %8s %8s %8s %8s %8s\n\n, ITEM, SIZE,
- LIMIT, USED, FREE, REQUESTS, FAILURES);
+ printf(%-20s %6s %6s %8s %8s %8s %4s %4s\n\n, ITEM, SIZE,
+ LIMIT, USED, FREE, REQ, FAIL, SLEEP);
for (mtp = memstat_mtl_first(mtlp); mtp != NULL;
mtp = memstat_mtl_next(mtp)) {
strlcpy(name, memstat_get_name(mtp), MEMTYPE_MAXNAME);
strcat(name, :);
- printf(%-20s %8llu, %8llu, %8llu, %8llu, %8llu, %8llu\n, name,
+ printf(%-20s %6llu, %6llu,%8llu,%8llu,%8llu,%4llu,%4llu\n,name,
memstat_get_size(mtp), memstat_get_countlimit(mtp),
memstat_get_count(mtp), memstat_get_free(mtp),
- memstat_get_numallocs(mtp), memstat_get_failures(mtp));
+ memstat_get_numallocs(mtp), memstat_get_failures(mtp),
+ memstat_get_sleeps(mtp));
}
memstat_mtl_free(mtlp);
printf(\n);
Index: lib/libmemstat/memstat.h
===
--- lib/libmemstat/memstat.h (revision 209161)
+++ lib/libmemstat/memstat.h (working copy)
@@ -139,6 +139,7 @@
uint64_t memstat_get_count(const struct memory_type *mtp);
uint64_t memstat_get_free(const struct memory_type *mtp);
uint64_t memstat_get_failures(const struct memory_type *mtp);
+uint64_t memstat_get_sleeps(const struct memory_type *mtp);
void *memstat_get_caller_pointer(const struct memory_type *mtp,
int index);
void memstat_set_caller_pointer(struct memory_type *mtp,
Index: lib/libmemstat/memstat.c
===
--- lib/libmemstat/memstat.c (revision 209161)
+++ lib/libmemstat/memstat.c (working copy)
@@ -188,6 +188,7 @@
mtp-mt_count = 0;
mtp-mt_free = 0;
mtp-mt_failures = 0;
+ mtp-mt_sleeps = 0;
mtp-mt_zonefree = 0;
mtp-mt_kegfree = 0;
@@ -304,6 +305,13 @@
return (mtp-mt_failures);
}
+uint64_t
+memstat_get_sleeps(const struct memory_type *mtp)
+{
+
+ return (mtp-mt_sleeps);
+}
+
void *
memstat_get_caller_pointer(const struct memory_type *mtp, int index)
{
Index: lib/libmemstat/memstat_internal.h
===
--- lib/libmemstat/memstat_internal.h (revision 209161)
+++ lib/libmemstat/memstat_internal.h (working copy)
@@ -65,6 +65,7 @@
uint64_t mt_count; /* Number of current allocations. */
uint64_t mt_free; /* Number of cached free items. */
uint64_t mt_failures; /* Number of allocation failures. */
+ uint64_t mt_sleeps; /* Number of allocation sleeps. */
/*
* Caller-owned memory.
Index: lib/libmemstat/memstat_uma.c
===
--- lib/libmemstat/memstat_uma.c (revision 209161)
+++ lib/libmemstat/memstat_uma.c (working copy)
@@ -208,6 +208,7 @@
mtp-mt_numallocs = uthp-uth_allocs;
mtp-mt_numfrees = uthp-uth_frees;
mtp-mt_failures = uthp-uth_fails;
+ mtp-mt_sleeps = uthp-uth_sleeps;
for (j = 0; j maxcpus; j++) {
upsp = (struct uma_percpu_stat *)p;
@@ -402,6 +403,7 @@
mtp-mt_numallocs = uz.uz_allocs;
mtp-mt_numfrees = uz.uz_frees;
mtp-mt_failures = uz.uz_fails;
+ mtp-mt_sleeps = uz.uz_sleeps;
if (kz.uk_flags UMA_ZFLAG_INTERNAL)
goto skip_percpu;
for (i = 0; i mp_maxid + 1; i++) {
Index: sys/vm/uma_int.h
===
--- sys/vm/uma_int.h (revision 209161)
+++ sys/vm/uma_int.h (working copy)
@@ -327,6 +327,7 @@
u_int64_t uz_allocs UMA_ALIGN; /* Total number of allocations */
u_int64_t uz_frees; /* Total number of frees */
u_int64_t uz_fails; /* Total number of alloc failures */
+ u_int64_t uz_sleeps; /* Total number of alloc sleeps */
uint16_t uz_fills; /* Outstanding bucket fills */
uint16_t uz_count; /* Highest value ub_ptr can have */
Index: sys/vm/uma.h
===
--- sys/vm/uma.h (revision 209161)
+++ sys/vm/uma.h (working copy)
@@ -600,7 +600,8 @@
u_int64_t uth_allocs; /* Zone: number of allocations. */
u_int64_t uth_frees; /* Zone: number of frees. */
u_int64_t uth_fails; /* Zone: number of alloc failures. */
- u_int64_t _uth_reserved1[3]; /* Reserved. */
+ u_int64_t uth_sleeps; /* Zone: number of alloc sleeps. */
+
Re: Checksum mismatch -- will transfer entire file
Victor Sudakov sudakov+free...@sibptus.tomsk.ru wrote: I see nobody is ever going to fix this? Cvsup mails me a bunch of Checksum mismatch errors on every run, with a risk of overlooking real errors. It is particularly egregious when a tag is laid down, like today. csup(1) ends up refetching a big chunk of the tree from scratch because so many files have these spurious checksum mismatches. Personally, I don't care too much, but quite a bit of mirror bandwidth is wasted this way. How do others deal with this noise? Do you grep cvsup output or what? I optimistically assume that there are no real errors and I run csup without -s once a week or so, just in case. -- Christian naddy Weisgerber na...@mips.inka.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Checksum mismatch -- will transfer entire file
Jonathan Noack wrote: But to hell with this. I started the topic because I think something is wrong with SVN to CVS export, which upsets cvsup and causes Checksum mismatch errors. Is anybody willing to look at it? I see nobody is ever going to fix this? Cvsup mails me a bunch of Checksum mismatch errors on every run, with a risk of overlooking real errors. How do others deal with this noise? Do you grep cvsup output or what? Seems like newer versions of CVS break assumptions made by CVSup on the ordering of branch revisions: http://lists.freebsd.org/pipermail/freebsd-hubs/2009-August/002083.html So, in short I don't see any easy solutions to this, and especially given the fact that in the long run CVS/CVSup will probably be replaced by something else for distributing FreeBSD source, I don't think it will be that easy to find someone to fix either CVSup or CVS. Thanks for the link. Somebody wrote here that the problem was perhaps in the svn2cvs script, but Simon's post gives a different outlook. Maybe nobody is going to fix CVSup (is it not actively developed already?), but csup is relatively recent and alive. Once it has a CVS mode, maybe it could be adjusted? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Checksum mismatch -- will transfer entire file
On Mon, June 14, 2010 00:43, Victor Sudakov wrote: Victor Sudakov wrote: But to hell with this. I started the topic because I think something is wrong with SVN to CVS export, which upsets cvsup and causes Checksum mismatch errors. Is anybody willing to look at it? I see nobody is ever going to fix this? Cvsup mails me a bunch of Checksum mismatch errors on every run, with a risk of overlooking real errors. How do others deal with this noise? Do you grep cvsup output or what? Seems like newer versions of CVS break assumptions made by CVSup on the ordering of branch revisions: http://lists.freebsd.org/pipermail/freebsd-hubs/2009-August/002083.html So, in short I don't see any easy solutions to this, and especially given the fact that in the long run CVS/CVSup will probably be replaced by something else for distributing FreeBSD source, I don't think it will be that easy to find someone to fix either CVSup or CVS. -Jon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
