Re: ar(1) format_decimal failure is fatal?
On Sep 17, 2010, at 9:01 PM, Benjamin Kaduk wrote:
> On Sun, 29 Aug 2010, Jilles Tjoelker wrote:
>
>> On Sat, Aug 28, 2010 at 07:08:34PM -0400, Benjamin Kaduk wrote:
>>> [...]
>>> building static egacy library
>>> ar: fatal: Numeric user ID too large
>>> *** Error code 70
>>
>>> This error appears to be coming from
>>> lib/libarchive/archive_write_set_format_ar.c , which seems to only have
>>> provisions for outputting a user ID in AR_uid_size = 6 columns.
> [...]
>>> It looks like this macro was so defined in version 1.1 of that file, with
>>> commit message "'ar' format support for libarchive, contributed by Kai
>>> Wang.". This doesn't make it terribly clear whether the 'ar' format
>>> mandates this length, or if it is an implementation decision...
There's no official standard for the ar format, only old
conventions and compatibility with legacy implementations.
>> I wonder if the uid/gid fields are useful at all for ar archives. Ar
>> archives are usually not extracted, and when they are, the current
>> user's values seem good enough. The uid/gid also prevent exactly
>> reproducible builds (together with the timestamp).
>
> GNU binutils has recently (well, March 2009) added a -D ("deterministic")
> argument to ar(1) which sets the timestamp, uid, and gid to zero, and the
> mode to 644. If that argument is not given, linux's ar(1) happily uses my
> 8-digit uid as-is; the manual page seems to imply that it will handle 15 or
> 16 digits in that field.
Please send me a small example file... I don't think I've seen
this format variant. Maybe we can extend our ar(1) to support
this variant.
Personally, I wonder if it wouldn't make sense to just always
force the timestamp, uid, and gid to zero. I find it hard
to believe anyone is using ar(1) as a general-purpose archiving
tool. Of course, it should be trivial to add -D support to our ar(1).
> I propose that format_{decimal,octal}() return ARCHIVE_FAILED for negative
> input, and ARCHIVE_WARN for overflow. archive_write_ar_header() can then
> catch ARCHIVE_WARN from the format_foo functions and continue on, propagating
> the ARCHIVE_WARN return value at the end of its execution ...
This sounds entirely reasonable to me. I personally don't see much
advantage to distinguishing negative versus overflow, but certainly
have no objections to that part. Definitely ar(1) should not abort on
a simple ARCHIVE_WARN.
> Would (one of) you be willing to review a patch to that effect?
Happy to do so.
Cheers,
Tim
___
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"
KDB_TRACE and no backend
Here's a small patch that adds support for printing stack trace in form of frame
addresses when KDB_TRACE is enabled, but there is no debugger backend
configured.
The patch is styled after "cheap" variant of stack_ktr.
What do you think (useful/useless, correct, etc) ?
--- a/sys/kern/subr_kdb.c
+++ b/sys/kern/subr_kdb.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
@@ -295,10 +296,16 @@
void
kdb_backtrace(void)
{
+ struct stack st;
+ int i;
- if (kdb_dbbe != NULL && kdb_dbbe->dbbe_trace != NULL) {
- printf("KDB: stack backtrace:\n");
+ printf("KDB: stack backtrace:\n");
+ if (kdb_dbbe != NULL && kdb_dbbe->dbbe_trace != NULL)
kdb_dbbe->dbbe_trace();
+ else {
+ stack_save(&st);
+ for (i = 0; i < st.depth; i++)
+ printf("#%d %p\n", i, (void*)(uintptr_t)st.pcs[i]);
}
}
--
Andriy Gapon
___
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: zfs + uma
On Fri, 17 Sep 2010, Andre Oppermann wrote: Although keeping free items around improves performance, it does consume memory too. And the fact that that memory is not freed on lowmem condition makes the situation worse. Interesting. We may run into related issues with excessive mbuf (cluster) caching in the per-cpu buckets as well. Having a general solutions for that is appreciated. Maybe the size of the free per-cpu buckets should be specified when setting up the UMA zone. Of certain frequently re-used elements we may want to cache more, other less. I've been keeping a vague eye out for this over the last few years, and haven't spotted many problems in production machines I've inspected. You can use the umastat tool in the tools tree to look at the distribution of memory over buckets (etc) in UMA manually. It would be nice if it had some automated statistics on fragmentation however. Short-lived fragmentation is likely, and isn't an issue, so what you want is a tool that monitors over time and reports on longer-lived fragmentation. The main fragmentation issue we've had in the past has been due to mbuf+cluster caching, which prevented mbufs from being freed usefully in some cases. Jeff's ongoing work on variable-sized mbufs would entirely eliminate that problem... Robert ___ 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: zfs + uma
on 18/09/2010 14:23 Robert Watson said the following: > I've been keeping a vague eye out for this over the last few years, and > haven't > spotted many problems in production machines I've inspected. You can use the > umastat tool in the tools tree to look at the distribution of memory over > buckets (etc) in UMA manually. It would be nice if it had some automated > statistics on fragmentation however. Short-lived fragmentation is likely, and > isn't an issue, so what you want is a tool that monitors over time and reports > on longer-lived fragmentation. > > The main fragmentation issue we've had in the past has been due to > mbuf+cluster > caching, which prevented mbufs from being freed usefully in some cases. > Jeff's > ongoing work on variable-sized mbufs would entirely eliminate that problem... Robert, just in case, this thread is not about fragmentation, it's about per-cpu buckets, number of items in them and size of the items. -- Andriy Gapon ___ 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: zfs + uma
On 18 Sep 2010, at 12:27, Andriy Gapon wrote: > on 18/09/2010 14:23 Robert Watson said the following: >> I've been keeping a vague eye out for this over the last few years, and >> haven't >> spotted many problems in production machines I've inspected. You can use the >> umastat tool in the tools tree to look at the distribution of memory over >> buckets (etc) in UMA manually. It would be nice if it had some automated >> statistics on fragmentation however. Short-lived fragmentation is likely, >> and >> isn't an issue, so what you want is a tool that monitors over time and >> reports >> on longer-lived fragmentation. >> >> The main fragmentation issue we've had in the past has been due to >> mbuf+cluster >> caching, which prevented mbufs from being freed usefully in some cases. >> Jeff's >> ongoing work on variable-sized mbufs would entirely eliminate that problem... > > just in case, this thread is not about fragmentation, it's about per-cpu > buckets, number of items in them and size of the items. Those issues are closely related, and in particular, wanted to point Andre at umastat since he's probably not aware of it.. :-) Robert___ 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: zfs + uma
Robert Watson wrote:
> On Fri, 17 Sep 2010, Andre Oppermann wrote:
>
> >> Although keeping free items around improves performance, it does consume
> >> memory too. And the fact that that memory is not freed on lowmem
> >> condition
> >> makes the situation worse.
> >
> > Interesting. We may run into related issues with excessive mbuf (cluster)
> > caching in the per-cpu buckets as well.
> >
> > Having a general solutions for that is appreciated. Maybe the size of the
> > free per-cpu buckets should be specified when setting up the UMA zone. Of
> > certain frequently re-used elements we may want to cache more, other less.
>
> I've been keeping a vague eye out for this over the last few years, and
> haven't spotted many problems in production machines I've inspected. You can
> use the umastat tool in the tools tree to look at the distribution of memory
> over buckets (etc) in UMA manually.
Doesn't build for me on amd64:
f...@r500 /usr/src/tools/tools/umastat $make
Warning: Object directory not changed from original /usr/src/tools/tools/umastat
cc -O2 -pipe -fno-omit-frame-pointer -std=gnu99 -fstack-protector
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
-Wno-pointer-sign -c umastat.c
cc1: warnings being treated as errors
umastat.c: In function 'uma_print_bucketlist':
umastat.c:234: warning: format '%llu' expects type 'long long unsigned int',
but argument 3 has type 'uint64_t'
umastat.c:234: warning: format '%llu' expects type 'long long unsigned int',
but argument 4 has type 'uint64_t'
umastat.c: In function 'uma_print_cache':
umastat.c:245: warning: format '%llu' expects type 'long long unsigned int',
but argument 3 has type 'u_int64_t'
umastat.c:246: warning: format '%llu' expects type 'long long unsigned int',
but argument 3 has type 'u_int64_t'
umastat.c: In function 'main':
umastat.c:416: warning: format '%llu' expects type 'long long unsigned int',
but argument 2 has type 'u_int64_t'
umastat.c:418: warning: format '%llu' expects type 'long long unsigned int',
but argument 2 has type 'u_int64_t'
umastat.c:420: warning: format '%llu' expects type 'long long unsigned int',
but argument 2 has type 'u_int64_t'
umastat.c:426: warning: dereferencing type-punned pointer will break
strict-aliasing rules
umastat.c:429: warning: dereferencing type-punned pointer will break
strict-aliasing rules
*** Error code 1
Stop in /usr/src/tools/tools/umastat.
The attached patch seems to work around the problem, I'm not sure if
the casts to void* are better than decreasing the WARN level, though ...
Fabian
From b84b5cf4f24b6886b5db9885f5bea707dcfb11e8 Mon Sep 17 00:00:00 2001
From: Fabian Keil
Date: Sat, 18 Sep 2010 13:55:54 +0200
Subject: [PATCH] Work around umastat build failures on amd64.
---
tools/tools/umastat/umastat.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/tools/umastat/umastat.c b/tools/tools/umastat/umastat.c
index 3c9fe0e..639bf80 100644
--- a/tools/tools/umastat/umastat.c
+++ b/tools/tools/umastat/umastat.c
@@ -230,7 +230,7 @@ uma_print_bucketlist(kvm_t *kvm, struct bucketlist *bucketlist,
}
printf("\n");
- printf("%s}; // total cnt %llu, total entries %llu\n", spaces,
+ printf("%s}; // total cnt %ju, total entries %ju\n", spaces,
total_cnt, total_entries);
}
@@ -242,8 +242,8 @@ uma_print_cache(kvm_t *kvm, struct uma_cache *cache, const char *name,
int ret;
printf("%s%s[%d] = {\n", spaces, name, cpu);
- printf("%s uc_frees = %llu;\n", spaces, cache->uc_frees);
- printf("%s uc_allocs = %llu;\n", spaces, cache->uc_allocs);
+ printf("%s uc_frees = %ju;\n", spaces, cache->uc_frees);
+ printf("%s uc_allocs = %ju;\n", spaces, cache->uc_allocs);
if (cache->uc_freebucket != NULL) {
ret = kread(kvm, cache->uc_freebucket, &ub, sizeof(ub), 0);
@@ -412,20 +412,20 @@ main(int argc, char *argv[])
}
printf(" Zone {\n");
printf("uz_name = \"%s\";\n", name);
- printf("uz_allocs = %llu;\n",
+ printf("uz_allocs = %ju;\n",
uzp_userspace->uz_allocs);
- printf("uz_frees = %llu;\n",
+ printf("uz_frees = %ju;\n",
uzp_userspace->uz_frees);
- printf("uz_fails = %llu;\n",
+ printf("uz_fails = %ju;\n",
uzp_userspace->uz_fails);
printf("uz_fills = %u;\n",
uzp_userspace->uz_fills);
printf("uz_count = %u;\n",
uzp_userspace->uz_count);
- uma_print_bucketlist(kvm, (struct bucketlist *)
+ uma_print_bucketlist(kvm, (void *)
&uzp_userspace->uz_full_bucket, "uz_full_bucket",
"");
- uma_print_bucketlist(kvm, (struct bucketlist *)
+ uma_print_bucketlist(kvm, (void *)
&uzp_userspace->uz_free_bucket, "uz_free_bucket",
"");
--
1.7.2.3
signature.asc
Description: PGP signature
Re: zfs + uma
on 18/09/2010 14:30 Robert N. M. Watson said the following: > Those issues are closely related, and in particular, wanted to point Andre at > umastat since he's probably not aware of it.. :-) I didn't know about the tool too, so thanks! But I perceived the issues as quite opposite: small items vs huge items. -- Andriy Gapon ___ 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: zfs + uma
On 18 Sep 2010, at 13:35, Fabian Keil wrote: > Doesn't build for me on amd64: > > f...@r500 /usr/src/tools/tools/umastat $make > Warning: Object directory not changed from original > /usr/src/tools/tools/umastat > cc -O2 -pipe -fno-omit-frame-pointer -std=gnu99 -fstack-protector > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized > -Wno-pointer-sign -c umastat.c > cc1: warnings being treated as errors > umastat.c: In function 'uma_print_bucketlist': > umastat.c:234: warning: format '%llu' expects type 'long long unsigned int', > but argument 3 has type 'uint64_t' > umastat.c:234: warning: format '%llu' expects type 'long long unsigned int', > but argument 4 has type 'uint64_t' > umastat.c: In function 'uma_print_cache': > umastat.c:245: warning: format '%llu' expects type 'long long unsigned int', > but argument 3 has type 'u_int64_t' > umastat.c:246: warning: format '%llu' expects type 'long long unsigned int', > but argument 3 has type 'u_int64_t' > umastat.c: In function 'main': > umastat.c:416: warning: format '%llu' expects type 'long long unsigned int', > but argument 2 has type 'u_int64_t' > umastat.c:418: warning: format '%llu' expects type 'long long unsigned int', > but argument 2 has type 'u_int64_t' > umastat.c:420: warning: format '%llu' expects type 'long long unsigned int', > but argument 2 has type 'u_int64_t' > umastat.c:426: warning: dereferencing type-punned pointer will break > strict-aliasing rules > umastat.c:429: warning: dereferencing type-punned pointer will break > strict-aliasing rules > *** Error code 1 > > Stop in /usr/src/tools/tools/umastat. > > The attached patch seems to work around the problem, I'm not sure if > the casts to void* are better than decreasing the WARN level, though ... This is a 32-bit/64-bit issue. Probably all pointers printing should be converted to %p, and large integer types to %ju and %jd, perhaps with a cast first to intmax_t or uintmax_t if required. Robert___ 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: zfs + uma
On Sat, Sep 18, 2010 at 6:52 AM, Robert N. M. Watson wrote: > > On 18 Sep 2010, at 13:35, Fabian Keil wrote: > >> Doesn't build for me on amd64: >> >> f...@r500 /usr/src/tools/tools/umastat $make >> Warning: Object directory not changed from original >> /usr/src/tools/tools/umastat >> cc -O2 -pipe -fno-omit-frame-pointer -std=gnu99 -fstack-protector >> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized >> -Wno-pointer-sign -c umastat.c >> cc1: warnings being treated as errors >> umastat.c: In function 'uma_print_bucketlist': >> umastat.c:234: warning: format '%llu' expects type 'long long unsigned int', >> but argument 3 has type 'uint64_t' >> umastat.c:234: warning: format '%llu' expects type 'long long unsigned int', >> but argument 4 has type 'uint64_t' >> umastat.c: In function 'uma_print_cache': >> umastat.c:245: warning: format '%llu' expects type 'long long unsigned int', >> but argument 3 has type 'u_int64_t' >> umastat.c:246: warning: format '%llu' expects type 'long long unsigned int', >> but argument 3 has type 'u_int64_t' >> umastat.c: In function 'main': >> umastat.c:416: warning: format '%llu' expects type 'long long unsigned int', >> but argument 2 has type 'u_int64_t' >> umastat.c:418: warning: format '%llu' expects type 'long long unsigned int', >> but argument 2 has type 'u_int64_t' >> umastat.c:420: warning: format '%llu' expects type 'long long unsigned int', >> but argument 2 has type 'u_int64_t' >> umastat.c:426: warning: dereferencing type-punned pointer will break >> strict-aliasing rules >> umastat.c:429: warning: dereferencing type-punned pointer will break >> strict-aliasing rules >> *** Error code 1 >> >> Stop in /usr/src/tools/tools/umastat. >> >> The attached patch seems to work around the problem, I'm not sure if >> the casts to void* are better than decreasing the WARN level, though ... > > This is a 32-bit/64-bit issue. Probably all pointers printing should be > converted to %p, and large integer types to %ju and %jd, perhaps with a cast > first to intmax_t or uintmax_t if required. All types were explicitly declared as u_int64_t, so I'd try this instead with PRIu64. Very few spots in the code today use void * (and the ones that do interface with kvm_read(3)). FWIW, kvm_read taking the second argument as unsigned long instead of void* seems a bit inconsistent: ssize_t kvm_read(kvm_t *kd, unsigned long addr, void *buf, size_t nbytes); ssize_t kvm_write(kvm_t *kd, unsigned long addr, const void *buf, size_t nbytes); but that's a different topic to look at later, if it really matters to anyone. Thanks, -Garrett umastat-64bit.diff Description: Binary data ___ 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: Why I can't trace linux process's childs with truss?
On Sun, Sep 12, 2010 at 05:01:09PM +0200, Mateusz Guzik wrote: > On Sun, Sep 12, 2010 at 3:08 PM, Alexander Best wrote: > > there's a PR related to this "issue" [1]. so is truss missing this > > functionality or is this in fact a feature, because truss musn't be used on > > any non freebsd executable? > > > > Actually truss handles linux processes just fine, except for their children. > :) > Linux process can create a child using linux_clone syscall, but truss does not > handle that case and this can be the problem that Yuri reported (since > no log was > provided, I can only guess). > > This trivial patch should fix this: > http://student.agh.edu.pl/~mjguzik/truss-linux-forks.patch This is too trivial, IMO. linux_clone() does not neccessary cause new process to be created, I think. > > Tested on this simple program: > http://student.agh.edu.pl/~mjguzik/fork.c > > If it still does not work, log generated by truss would be helfpul. pgp2m7o9owCbC.pgp Description: PGP signature
Re: zfs + uma
On 18 September 2010 17:52, Robert N. M. Watson wrote: > > On 18 Sep 2010, at 13:35, Fabian Keil wrote: > >> Doesn't build for me on amd64: >> >> f...@r500 /usr/src/tools/tools/umastat $make >> Warning: Object directory not changed from original >> /usr/src/tools/tools/umastat >> cc -O2 -pipe -fno-omit-frame-pointer -std=gnu99 -fstack-protector >> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized >> -Wno-pointer-sign -c umastat.c >> cc1: warnings being treated as errors >> umastat.c: In function 'uma_print_bucketlist': >> umastat.c:234: warning: format '%llu' expects type 'long long unsigned int', >> but argument 3 has type 'uint64_t' >> umastat.c:234: warning: format '%llu' expects type 'long long unsigned int', >> but argument 4 has type 'uint64_t' >> umastat.c: In function 'uma_print_cache': >> umastat.c:245: warning: format '%llu' expects type 'long long unsigned int', >> but argument 3 has type 'u_int64_t' >> umastat.c:246: warning: format '%llu' expects type 'long long unsigned int', >> but argument 3 has type 'u_int64_t' >> umastat.c: In function 'main': >> umastat.c:416: warning: format '%llu' expects type 'long long unsigned int', >> but argument 2 has type 'u_int64_t' >> umastat.c:418: warning: format '%llu' expects type 'long long unsigned int', >> but argument 2 has type 'u_int64_t' >> umastat.c:420: warning: format '%llu' expects type 'long long unsigned int', >> but argument 2 has type 'u_int64_t' >> umastat.c:426: warning: dereferencing type-punned pointer will break >> strict-aliasing rules >> umastat.c:429: warning: dereferencing type-punned pointer will break >> strict-aliasing rules >> *** Error code 1 >> >> Stop in /usr/src/tools/tools/umastat. >> >> The attached patch seems to work around the problem, I'm not sure if >> the casts to void* are better than decreasing the WARN level, though ... > > This is a 32-bit/64-bit issue. Probably all pointers printing should be > converted to %p, and large integer types to %ju and %jd, perhaps with a cast > first to intmax_t or uintmax_t if required. > FYI, There is a PR 146119 about sort of fixing that issues. -- wbr, pluknet ___ 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: KDB_TRACE and no backend
2010/9/18 Andriy Gapon :
>
> Here's a small patch that adds support for printing stack trace in form of
> frame
> addresses when KDB_TRACE is enabled, but there is no debugger backend
> configured.
> The patch is styled after "cheap" variant of stack_ktr.
>
> What do you think (useful/useless, correct, etc) ?
>
> --- a/sys/kern/subr_kdb.c
> +++ b/sys/kern/subr_kdb.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -295,10 +296,16 @@
> void
> kdb_backtrace(void)
> {
> + struct stack st;
> + int i;
>
> - if (kdb_dbbe != NULL && kdb_dbbe->dbbe_trace != NULL) {
> - printf("KDB: stack backtrace:\n");
> + printf("KDB: stack backtrace:\n");
> + if (kdb_dbbe != NULL && kdb_dbbe->dbbe_trace != NULL)
> kdb_dbbe->dbbe_trace();
> + else {
> + stack_save(&st);
> + for (i = 0; i < st.depth; i++)
> + printf("#%d %p\n", i, (void*)(uintptr_t)st.pcs[i]);
> }
> }
You have to eventually wrap this logic within the 'STACK' option
(opt_stack.h for the check) because stack_save() will be uneffective
otherwise. STACK should be mandatory for DDB I guess, but it is not
for KDB.
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
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: KDB_TRACE and no backend
on 18/09/2010 21:26 Attilio Rao said the following: > > You have to eventually wrap this logic within the 'STACK' option > (opt_stack.h for the check) because stack_save() will be uneffective > otherwise. STACK should be mandatory for DDB I guess, but it is not > for KDB. Thank you for the tip! BTW, why is this under an option? It seems like something like this won't add much to kernel size and won't affect performance at all. -- Andriy Gapon ___ 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: zfs + uma
> FWIW, kvm_read taking the second argument as unsigned long instead of > void* seems a bit inconsistent: I think it done on purpose, since address in the kernel address space has nothing to do with pointers for mere userland mortals. We shouldn't bother compiler with aliasing and other stuff in case of kernel addresses. //Marcin ___ 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: KDB_TRACE and no backend
on 18/09/2010 21:41 Andriy Gapon said the following: > on 18/09/2010 21:26 Attilio Rao said the following: >> >> You have to eventually wrap this logic within the 'STACK' option >> (opt_stack.h for the check) because stack_save() will be uneffective >> otherwise. STACK should be mandatory for DDB I guess, but it is not >> for KDB. > > Thank you for the tip! > BTW, why is this under an option? > It seems like something like this won't add much to kernel size and won't > affect > performance at all. > Oh, wow, and I totally overlooked stack_print(). Should have read stack(9) from the start. -- Andriy Gapon ___ 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: KDB_TRACE and no backend
on 18/09/2010 22:00 Andriy Gapon said the following:
> Oh, wow, and I totally overlooked stack_print().
> Should have read stack(9) from the start.
New patch. Hope this is better.
I don't like that the printf is duplicated, but couldn't figure out a way to
combine pre-processor and C conditions.
--- a/sys/kern/subr_kdb.c
+++ b/sys/kern/subr_kdb.c
@@ -37,6 +37,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
@@ -300,6 +301,15 @@ kdb_backtrace(void)
printf("KDB: stack backtrace:\n");
kdb_dbbe->dbbe_trace();
}
+#ifdef STACK
+ else {
+ struct stack st;
+
+ printf("KDB: stack backtrace:\n");
+ stack_save(&st);
+ stack_print(&st);
+ }
+#endif
}
/*
--
Andriy Gapon
___
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: KDB_TRACE and no backend
2010/9/18 Andriy Gapon :
> on 18/09/2010 22:00 Andriy Gapon said the following:
>> Oh, wow, and I totally overlooked stack_print().
>> Should have read stack(9) from the start.
>
> New patch. Hope this is better.
> I don't like that the printf is duplicated, but couldn't figure out a way to
> combine pre-processor and C conditions.
>
> --- a/sys/kern/subr_kdb.c
> +++ b/sys/kern/subr_kdb.c
> @@ -37,6 +37,7 @@ __FBSDID("$FreeBSD$");
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -300,6 +301,15 @@ kdb_backtrace(void)
> printf("KDB: stack backtrace:\n");
> kdb_dbbe->dbbe_trace();
> }
> +#ifdef STACK
> + else {
> + struct stack st;
> +
> + printf("KDB: stack backtrace:\n");
> + stack_save(&st);
> + stack_print(&st);
> + }
> +#endif
> }
>
> /*
>
It is still missing checking on opt_stack.h
Besides, I'd reconsider having KDB_TRACE explanation in ddb(4) manpage
(right now it is rightly there because it is DDB specific only, as
long as it offers the backend, but with your change it is a global
functionality. Not sure if it worths changing it but however you may
have more opinions).
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
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: KDB_TRACE and no backend
on 18/09/2010 23:35 Attilio Rao said the following: > It is still missing checking on opt_stack.h Yes, thanks, fixed it in my tree. > Besides, I'd reconsider having KDB_TRACE explanation in ddb(4) manpage > (right now it is rightly there because it is DDB specific only, as > long as it offers the backend, but with your change it is a global > functionality. Not sure if it worths changing it but however you may > have more opinions). It seems that we don't have kdb(4) ? -- Andriy Gapon ___ 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: KDB_TRACE and no backend
2010/9/18 Andriy Gapon : > on 18/09/2010 23:35 Attilio Rao said the following: >> It is still missing checking on opt_stack.h > > Yes, thanks, fixed it in my tree. > >> Besides, I'd reconsider having KDB_TRACE explanation in ddb(4) manpage >> (right now it is rightly there because it is DDB specific only, as >> long as it offers the backend, but with your change it is a global >> functionality. Not sure if it worths changing it but however you may >> have more opinions). > > It seems that we don't have kdb(4) ? > We don't and we should really have. I'd really like a kernel section describing the whole kdb infrastructure and kdbe hooks. That may be indicated as a janitor taks actually if someone wants to takeover and document the whole layer. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: ar(1) format_decimal failure is fatal?
Tim Kientzle wrote: > Personally, I wonder if it wouldn't make sense to just always > force the timestamp, uid, and gid to zero .. uid and gid, OK. Timestamp, no. It is not that rare to need to find out which version of some .o is in a particular .a file, usually in connection with debugging some obscure failure. For that matter, aren't there some versions of make(1) that can check whether an archive member is up to date by examining the timestamp in the archive? ___ 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: zfs + uma
On Sat, 18 Sep 2010, Robert Watson wrote: On Fri, 17 Sep 2010, Andre Oppermann wrote: Although keeping free items around improves performance, it does consume memory too. And the fact that that memory is not freed on lowmem condition makes the situation worse. Interesting. We may run into related issues with excessive mbuf (cluster) caching in the per-cpu buckets as well. Having a general solutions for that is appreciated. Maybe the size of the free per-cpu buckets should be specified when setting up the UMA zone. Of certain frequently re-used elements we may want to cache more, other less. I've been keeping a vague eye out for this over the last few years, and haven't spotted many problems in production machines I've inspected. You can use the umastat tool in the tools tree to look at the distribution of memory over buckets (etc) in UMA manually. It would be nice if it had some automated statistics on fragmentation however. Short-lived fragmentation is likely, and isn't an issue, so what you want is a tool that monitors over time and reports on longer-lived fragmentation. Not specifically in reaction to Robert's comment but I would like to add my thoughts to this notion of resource balancing in buckets. I really prefer not to do any specific per-zone tuning except in extreme cases. This is because quite often the decisions we make don't apply to some class of machines or workloads. I would instead prefer to keep the algorithm adaptable. I like the idea of weighting the bucket decisions by the size of the item. Obviously this has some flaws with compound objects but in the general case it is good. We should consider increasing the cost of bucket expansion based on the size of the item. Right now buckets are expanded fairly readily. We could also consider decreasing the default bucket size for a zone based on vm pressure and use. Right now there is no downward pressure on bucket size, only upward based on trips to the slab layer. Additionally we could make a last ditch flush mechanism that runs on each cpu in turn and flushes some or all of the buckets in per-cpu caches. Presently that is not done due to synchronization issues. It can't be done from a central place. It could be done with a callout mechanism or a for loop that binds to each core in succession. I believe the combination of these approaches would significantly solve the problem and should be relatively little new code. It should also preserve the adaptable nature of the system without penalizing resource heavy systems. I would be happy to review patches from anyone who wishes to undertake it. The main fragmentation issue we've had in the past has been due to mbuf+cluster caching, which prevented mbufs from being freed usefully in some cases. Jeff's ongoing work on variable-sized mbufs would entirely eliminate that problem... I'm going to get back to this soon as infiniband gets to a useful state for doing high performance network testing. This is only because I have no 10gigE but do have ib and have funding to cover working on it. I hope to have some results and activity on this front by the end of the year. I know it has been long coming. Thanks, Jeff Robert ___ 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"
