if the code handles the case when a new 'soonest' callout is
scheduled after we already decided when to fire the next LAPIC timer interrupt.
Thank you very much again!
Please keep up the good work :)
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing
this, there is
freebsd-questions@
--
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
on 30/03/2010 19:43 Andriy Gapon said the following:
do you think that periodic saving of system clock to hardware and making
resettodr
asynchronous are dependent issues? Or are they orthogonal and can be
implemented
independently?
A new version of the patch:
http://people.freebsd.org
FreeBSD? Or perhaps by creating your own bootable/live FreeBSD CD?
--
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
on 06/04/2010 15:47 Andriy Gapon said the following:
on 30/03/2010 19:43 Andriy Gapon said the following:
do you think that periodic saving of system clock to hardware and making
resettodr
asynchronous are dependent issues? Or are they orthogonal and can be
implemented
independently
a character from a message buffer.
* Returns the character, or -1 if no characters are available.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail
article on my toying with some
LiveCD creation methods:
http://wiki.freebsd.org/AvgLiveCD
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers
and
modules paths, those should be /boot/kernel and /boot/modules.
Make sure that you have a large enough message buffer size and boot with verbose
messages enabled. kernel will report pre-loaded modules at the start of boot.
Check there for any error reports from kernel linker too.
--
Andriy
on 18/04/2010 13:21 Garrett Cooper said the following:
On Sun, Apr 18, 2010 at 12:52 AM, Andriy Gapon a...@icyb.net.ua wrote:
on 18/04/2010 06:11 Yoshihiro Ota said the following:
If you want to make a bootable FreeBSD CD, take a look at
freesbie in ports. That's what the software does.
I
. Is it based on some technical
aspects,
or license, or something else?
Thanks a lot!
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers
There was no excitement over the proposed patch on rc@, perhaps more luck here
:-)
Original Message
Subject: rc.d/root: handle filesystems with r/o support only
Date: Sat, 17 Apr 2010 22:16:30 +0300
From: Andriy Gapon a...@icyb.net.ua
To: freebsd...@freebsd.org
Could you
was.
Hope this would be a useful reading.
--
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
such a shim that you could share?
I'd be much obliged for it. And not only I, I think.
Thanks!
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd
on 28/05/2010 17:49 Doug Rabson said the following:
On 27 May 2010 16:13, Andriy Gapon a...@icyb.net.ua
mailto:a...@icyb.net.ua wrote:
on 27/05/2010 17:40 Doug Rabson said the following:
Excellent work - thanks for looking into this. I still think its
easier
the children to have their own private mount
namespaces.
I am afraid that FreeBSD doesn't have this capability.
There is a single mount namespace per whole system image.
BTW, I am intrigued, in what situations this flag is useful?
--
Andriy Gapon
in all places that need to
map loaded module's sections to load addresses?
What do you think?
Thanks!
P.S.
As I understand CTF data includes a symbol table.
What kind of symbol addresses is used there? Are they relative within a
corresponding section? Or something else?
--
Andriy Gapon
(relocatable object file)
similarly to how they are set in i386 .ko (full-blown DSO)?
Or is this too much useless hassle?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe
on 21/06/2010 23:44 Navdeep Parhar said the following:
On Mon, Jun 21, 2010 at 04:10:45PM -0400, John Baldwin wrote:
On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote:
on 21/06/2010 18:43 John Baldwin said the following:
np@ has a patch to gdb to fix this for kgdb. I haven't committed
pointless.
[IMHO :-)]
--
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
on 22/06/2010 00:34 Andriy Gapon said the following:
gdb change - I'd rather do it via kld_current_sos,
kld_relocate_section_addresses. I'd like to avoid changing common gdb code
for
a variety of reasons.
I came up with the following patch.
EXEC_P and DYNAMIC flags are bfd library
./cuse4bsd.ko:3184 d cuse_kern_uninit_sys_uninit
/cite
--
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
on 23/06/2010 09:52 Hans Petter Selasky said the following:
On Wednesday 23 June 2010 08:47:52 Andriy Gapon wrote:
on 23/06/2010 03:38 Hans Petter Selasky said the following:
Hi,
I'm creating a new thread on this issue.
On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote:
I saw
on 23/06/2010 10:02 Andriy Gapon said the following:
I don't dispute that it is found broken in particular environments, I just
think
that the analysis could be incorrect.
Which also brings the question - what arch(s) is affected?
I tested on amd64.
--
Andriy Gapon
on 23/06/2010 18:03 Ryan Stone said the following:
On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon a...@icyb.net.ua wrote:
Which also brings the question - what arch(s) is affected?
I tested on amd64.
This should explain it. It looks to me like i386 uses kern/link_elf.c
as its linker, while
:
--
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
and libraries:
+* [Text][R/O data][R/W data][Dynamic][BSS][Non loadable]
+*/
+ dmp-dm_text_size = dmp-dm_data_va - dmp-dm_text_va;
#if defined(__i386__)
/*
* Find the first load section and figure out the relocation
--
Andriy Gapon
on 02/07/2010 11:29 Bjoern A. Zeeb said the following:
On Fri, 25 Jun 2010, Andriy Gapon wrote:
Hey,
Proposed patch skips zero sized sections without going into trouble of
allocating section entry (progtab), doing zero-sized memory allocs and
copies.
I observe that sometimes zero-sized
on 05/07/2010 20:12 Bjoern A. Zeeb said the following:
On Mon, 5 Jul 2010, Andriy Gapon wrote:
on 02/07/2010 11:29 Bjoern A. Zeeb said the following:
On Fri, 25 Jun 2010, Andriy Gapon wrote:
Hey,
Proposed patch skips zero sized sections without going into trouble of
allocating section
0008 pcpu_entry_dpcpu_nvram1
0008 l O set_pcpu 0008 pcpu_entry_dpcpu_nvram2
ld set_pcpu
Looks good to me.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org
? Don't we explicitly create a section with aw flags?
And why do we need a (universal) initializer? Why is it mentioned here at all?
Educate me. I demand it! :-)
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org
on 09/07/2010 13:34 Andriy Gapon said the following:
Having thought and experimented more, I don't see why we need inline assembly
at
all and why DPCPU_DEFINE can not simply be defined as follows:
#define DPCPU_DEFINE(t, n)\
t DPCPU_NAME(n) __section(set_pcpu) \
__aligned
on 11/07/2010 14:54 Andriy Gapon said the following:
For completeness, here is a patch that simply drops the inline assembly and
the
comment about it, and GCC-generated assembly and its diff:
http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch
http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s
[oops, sorry, this is not a dup - corrected some omissions/mistakes]
on 11/07/2010 14:54 Andriy Gapon said the following:
For completeness, here is a patch that simply drops the inline assembly and
the
comment about it, and GCC-generated assembly and its diff:
http://people.freebsd.org/~avg
on 12/07/2010 00:15 Jeff Roberson said the following:
On Sun, 11 Jul 2010, Andriy Gapon wrote:
[oops, sorry, this is not a dup - corrected some omissions/mistakes]
on 11/07/2010 14:54 Andriy Gapon said the following:
For completeness, here is a patch that simply drops the inline
on 12/07/2010 00:38 Andriy Gapon said the following:
on 12/07/2010 00:15 Jeff Roberson said the following:
[snip]
I appreciate your analysis but I don't understand the motivation for
changing working code.
Primary reason is that the working code produces zero-sized
unused/unnecessary
I
on 11/07/2010 15:23 Andriy Gapon said the following:
on 11/07/2010 14:54 Andriy Gapon said the following:
For completeness, here is a patch that simply drops the inline assembly and
the
comment about it, and GCC-generated assembly and its diff:
http://people.freebsd.org/~avg/dpcpu
it.
Even if yes, I think that such changes make potential import of
newer binutils harder.
How?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail
outdated/misleading/not-descriptive-enough?
--
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
on 25/07/2010 02:31 RW said the following:
On Sat, 24 Jul 2010 23:23:07 +0300
Andriy Gapon a...@freebsd.org wrote:
There is a good deal of comments in the vm_pageout.c code that imply
that we use a hysteresis approach to deal with low available pages
condition.
In general, the hysteresis
on 25/07/2010 16:41 RW said the following:
On Sun, 25 Jul 2010 13:07:21 +0300
Andriy Gapon a...@freebsd.org wrote:
on 25/07/2010 02:31 RW said the following:
As I understand it the hysteresis is done inside vm_pageout_scan,
and the expectation is that one pass will typically satisfy
on 25/07/2010 23:28 RW said the following:
On Sun, 25 Jul 2010 17:19:41 +0300
Andriy Gapon a...@freebsd.org wrote:
on 25/07/2010 16:41 RW said the following:
In FreeBSD the inactive queue contains disk cache pages which
normally provide most of the clean pages needed. In addition pages
on 25/07/2010 23:43 Andriy Gapon said the following:
on 25/07/2010 23:28 RW said the following:
I didn't say it say it was guaranteed. I just think the scenario where
a first pass ends up between the watermarks is rare. And when it
happens I don't see a compelling reason to do extra paging
situation and so we would have to do
some heavy-lifting anyways. In my opinion, it's better to start doing more work
at once than trying to pretend that situation would somehow resolve itself.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing
use amd64 variant?
If yes, can you reproduce the problem with i386?
--
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
on 29/07/2010 19:13 Andriy Gapon said the following:
on 29/07/2010 17:13 Alexander Fiveg said the following:
P.S. Details about hardware and used software:
1. /var/run/dmesg.boot :
...
CPU: Dual Core AMD Opteron(tm) Processor 865 (1800.01-MHz 686-class CPU)
Origin = AuthenticAMD Id
on 29/07/2010 19:45 Alexander Fiveg said the following:
On Thursday 29 July 2010 18:13:23 Andriy Gapon wrote:
on 29/07/2010 17:13 Alexander Fiveg said the following:
P.S. Details about hardware and used software:
1. /var/run/dmesg.boot :
...
CPU: Dual Core AMD Opteron(tm) Processor 865
on 29/07/2010 23:02 Sergey Babkin said the following:
Jul 29, 2010 12:58:07 PM, a...@icyb.net.ua wrote:
on 29/07/2010 19:13 Andriy Gapon said the following:
on 29/07/2010 17:13 Alexander Fiveg said the following:
In fact I have a suspicion that the problem might have to do with multiple
mapping
4. hope that more knowledgeable people (experts) provide their advice, keep
nudging them via mailing list(s) :-)
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe
://people.freebsd.org/~avg/w83977.diff
There are quite a few possibilities about how this chip could be wired and
programmed (e.g. watchdog output may go to any of three multifunctional pins),
but
I really implemented only one configuration (the one that I actually had).
--
Andriy Gapon
with the patch, but they are changing all the time
depending on system usage.
I couldn't think of any good test that would reflect real-world usage patterns,
which I believe to be not entirely random.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing
kmem_cache:
http://docs.sun.com/app/docs/doc/816-5180/kmem-cache-create-9f?a=view
--
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
speak for themselves.
--
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
://people.freebsd.org/~avg/arc3.png
What do you see? What do you think?
--
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
and very significant portion of memory is
effectively lost to it.
E.g. ARC may think that it uses only 1GB but another 1GB is used by free items
in ZFS zones (of 4GB total).
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http
it
as successfully initialized, but I haven't looked at the actual code.
--
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
* ? :-) ]
--
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
with the option for debug enabled. That'll get you
some
output. :)
Guys asking questions about firefox, etc, why do you do that? :)
Did you misread system freeze as firefox freeze?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http
without
loading the .kld file ?
As I've already suggested the symbols are in *.symbols files.
If you have those then they should be loaded automatically, as John has
suggested.
If you don't have them, then arrange to have them.
--
Andriy Gapon
;
+
+ pa = PAGE_SHIFT;
+ idx = pa 6; /* 2^6 = 64 */
+ bit = pa 63;
+ vm_page_dump[idx] = ~(1ul bit);
+}
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
on 03/09/2010 19:10 Matthew Jacob said the following:
You can do it this way, but IMO, the best thing to do is to when you're
panicing
stop all other CPUs.
Entirely agree, that's the way it should be handled.
Unfortunately, all I could come up with was the patch that I posted.
--
Andriy
of page size. Internally they would still consume multiple of
page size per item, so we potentially can have two zones that use the same
number of pages per zone, but with different item size. With the patch they are
collapsed into a single zone.
--
Andriy Gapon
diff --git a/sys/vm/uma_core.c b
of flexibility seems like a very good idea.
--
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
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
, 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
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
, 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
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
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
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
on item size
seems to work rather well too, as my testing with zfs+uma shows.
I will also try to add code to completely bypass the per-cpu cache for really
huge items.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org
-cpu caching and are very large why even use UMA?
Good point.
Right now I am running with 4 items/bucket limit for items larger than 32KB.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
on 19/09/2010 11:27 Jeff Roberson said the following:
On Sun, 19 Sep 2010, Andriy Gapon wrote:
on 19/09/2010 01:16 Jeff Roberson said the following:
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
on 19/09/2010 11:42 Andriy Gapon said the following:
on 19/09/2010 11:27 Jeff Roberson said the following:
I don't like this because even with very large buffers you can still have
high
enough turnover to require per-cpu caching. Kip specifically added UMA
support
to address this issue
condition?
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.
--
Andriy Gapon
some early patches to implement first two of your suggestions and
I am testing them now. Looks good to me so far.
Parameters in the adaptions would probably need some additional tuning.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http
on 21/09/2010 09:35 Jeff Roberson said the following:
On Tue, 21 Sep 2010, Andriy Gapon wrote:
on 19/09/2010 01:16 Jeff Roberson said the following:
Additionally we could make a last ditch flush mechanism that runs on each
cpu in
How would you qualify a last ditch trigger?
Would
behavior, works well, but haven't tested per-CPU
cache draining yet:
http://people.freebsd.org/~avg/uma-2.diff
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail
on 22/09/2010 10:25 Andriy Gapon said the following:
2. patch that attempts to implement Jeff's three suggestions; I've tested
per-CPU cache size adaptive behavior, works well, but haven't tested per-CPU
cache draining yet:
http://people.freebsd.org/~avg/uma-2.diff
Now I've fully tested
is simpler, like a bug in your code :-)
You can do 'readelf -a' on a module that you load and check attributes of .data
section and then compare with data_sh that you get at run-time.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http
variable in empty test module, and Im looking at the
memory to determine
it's location. I'm not sure what is wrong then.
Can you post a link to the compiled test module?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http
on 29/09/2010 17:44 PL said the following:
Dnia 29-09-2010 o godz. 16:23 Andriy Gapon napisał(a):
on 29/09/2010 17:13 PL said the following:
It seems like it is not a problem in my own code, since readelf -S on a
elf file
gives me the same results as my debug messages. I've created an empty
whether to use SYSCTL_ADD_UINT or SYSCTL_ADD_ULONG
depending on real type behind vm_size_t.
Comments, suggestions?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any
on 30/09/2010 21:52 Garrett Cooper said the following:
On Thu, Sep 30, 2010 at 10:17 AM, Andriy Gapon a...@icyb.net.ua wrote:
Here's a patch that adds a sysctl for querying kmem_map-size, which may be
useful
for system state/resources monitoring:
http://people.freebsd.org/~avg/sysctl
on 30/09/2010 20:17 Andriy Gapon said the following:
Here's a patch that adds a sysctl for querying kmem_map-size, which may be
useful
for system state/resources monitoring:
http://people.freebsd.org/~avg/sysctl-kmem_map_size.diff
I am quite unsure about sizeof(kmem_map-size) == sizeof
A simple, probably incomplete and perhaps incorrect patch for
ru_inblock/ru_oublock accounting in zfs:
http://people.freebsd.org/~avg/zfs-ru.diff
Still quite better than nothing.
P.S.
This is about top -m io.
--
Andriy Gapon
___
freebsd-hackers
of it. But this is not necessary, of
course.
Big thanks to mdf@ for the hint and to kib@ and kan@ for memory model expertise.
P.S.
The assembly:
.loc 1 544 0
movlpanic_cpu(%rip), %eax
.LVL134:
.p2align 4,,7
.L210:
cmpl$255, %eax
jne .L210
jmp .L225
--
Andriy
-specific suspend_cpus()
function use generic_stop_cpus() instead of rolling out essentially duplicate
code. I couldn't see any reason no to consolidate, but perhaps I missed
something.
Big thanks to Matthew and his employer for the idea and example.
--
Andriy Gapon
on 05/10/2010 18:27 Andriy Gapon said the following:
Here's an updated patch:
http://people.freebsd.org/~avg/sysctl-kmem_map_size2.diff
The new code wraps kmem_map-size into SYSCTL_PROC() to handle vm_size_t type
differences for different platforms. The idea is suggested by Ed Maste.
So I am
on 07/10/2010 20:33 Andriy Gapon said the following:
A simple, probably incomplete and perhaps incorrect patch for
ru_inblock/ru_oublock accounting in zfs:
http://people.freebsd.org/~avg/zfs-ru.diff
I've updated the patch at the same location.
Thanks to swell.k for pointing out
you.
--
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
of the macro should do the check on their own if they expect zero as input (many
places in the do not allow that).
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any
and
[snip]
does this limitation still exist?
I don't think so.
--
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
the syscall.
Also tested, the demo syscall module:
After commit r205320 and, apparently, its MFC you need to prefix the module with
sys/. For example:
modstat(modfind(sys/syscall), stat);
P.S.
Perhaps a KPI breakage in a stable branch?
--
Andriy Gapon
to operate both on coredumps and on the live system.
We still need to commit the libprocstat itself,
though.
Just to let you know that I am eagerly awaiting for that to happen.
Perhaps even could help with something if you'd need that.
--
Andriy Gapon
on 12/11/2010 15:58 Stanislav Sedov said the following:
On Fri, 12 Nov 2010 14:14:47 +0200
Andriy Gapon a...@freebsd.org mentioned:
Just to let you know that I am eagerly awaiting for that to happen.
Perhaps even could help with something if you'd need that.
Review can certainly help
CPUTPM2_EFFREQ 0x0001
+
+/*
* Important bits in the AMD extended cpuid flags
*/
#defineAMDID_SYSCALL 0x0800
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe
further down to sched_clock() and handled there
too.
--
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
into the tree - this, most probably, has to be controlled by a
tunable/sysctl.
--
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
BUILDNAME=sbruno CHROOTDIR=/new_release
BTW, just in case, I think that EXTSRCDIR could be used to make a release out of
an existing src directory as opposed to code in a repository.
--
Andriy Gapon
--
Andriy Gapon
___
freebsd-hackers@freebsd.org
on 22/11/2010 01:18 Paul B Mahol said the following:
On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon a...@freebsd.org wrote:
As is - this is a perfect candidate for a local only patch.
To be included into the tree - this, most probably, has to be controlled by a
tunable/sysctl.
So solution
201 - 300 of 613 matches
Mail list logo
