On Sat, Apr 09, 2011 at 04:09:40AM +0100, Mindaugas Rasiukevicius wrote:
> Lars Heidieker wrote:
> > >> this is a part of the changes to the kernel memory management.
> > >> It's a changing the subr_extent to use kmem(9) instead of malloc(9)
> > >> essentially removing the MALLOC_TYPE from it.
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/09/11 12:25, Lars Heidieker wrote:
>
>
>> Third problem i.e. vmem(9) relying on malloc(9) is something
>> what
> needs
>> fixing, yes. VMEM_ADDR_NULL being 0 does not look like a major
> problem,
>> a simple offsetting would work around it, but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/09/11 05:09, Mindaugas Rasiukevicius wrote:
> Lars Heidieker wrote:
this is a part of the changes to the kernel memory management.
It's a changing the subr_extent to use kmem(9) instead of malloc(9)
essentially removing the MALLO
Lars Heidieker wrote:
> >> this is a part of the changes to the kernel memory management.
> >> It's a changing the subr_extent to use kmem(9) instead of malloc(9)
> >> essentially removing the MALLOC_TYPE from it.
> > Why start from this end, instead of converting extent(9) uses to vmem(9)
> > and
On Wed, Apr 06, 2011 at 12:43:16PM -0400, Thor Lancelot Simon wrote:
> In practice, it is entirely feasible to have a small set of DTrace
> probes always running. Start them at boot time, let them run. This
> is the kind of case where the ability to summarize data (counts,
> histograms, etc.) is
On Wed, Apr 06, 2011 at 12:43:16PM -0400, Thor Lancelot Simon wrote:
> On Wed, Apr 06, 2011 at 06:34:15PM +0200, Manuel Bouyer wrote:
> >
> > The point it: I don't want probes to be temporarily. When you notice a
> > problem it's too late to start the probe.
>
> How can you have both things you s
On Wed, Apr 06, 2011 at 06:34:15PM +0200, Manuel Bouyer wrote:
>
> The point it: I don't want probes to be temporarily. When you notice a
> problem it's too late to start the probe.
How can you have both things you seem to want? In your other message,
you seemed concerned that (you thought) DTra
On Wed, Apr 06, 2011 at 06:21:30PM +0200, Manuel Bouyer wrote:
>
> Maybe I don't understand how dtrace works then, but I though installed/started
> it generates a continous flow of events which are monitored, which have
> to be retrieved from userland. Isn't it how this works ?
No.
The basic uni
On Wed, Apr 06, 2011 at 05:29:18PM +0100, Mindaugas Rasiukevicius wrote:
> Manuel Bouyer wrote:
> > <...>
> > - I'm not sure you want to have dtrace running on a production server.
> >
> > KMEMSTATS is more than pure debugging purpose, it also helps with
> > tuning, and figuring out temporary ove
Manuel Bouyer wrote:
> <...>
> - I'm not sure you want to have dtrace running on a production server.
>
> KMEMSTATS is more than pure debugging purpose, it also helps with
> tuning, and figuring out temporary overload.
DTrace was *designed* as suitable for production systems.
It does not requir
On Wed, Apr 06, 2011 at 12:14:27PM -0400, Thor Lancelot Simon wrote:
> On Wed, Apr 06, 2011 at 06:05:49PM +0200, Manuel Bouyer wrote:
> >
> > - dtrace doesn't work everywhere (acutally I guess it's only x86, without
> > Xen)
>
> If new code is going to be written to implement (or reimplement) d
On Wed, Apr 06, 2011 at 06:05:49PM +0200, Manuel Bouyer wrote:
>
> - dtrace doesn't work everywhere (acutally I guess it's only x86, without
> Xen)
If new code is going to be written to implement (or reimplement) debugging
facilities I would strongly advocate that enhancing DTrace to work on mo
On Wed, Apr 06, 2011 at 05:53:00PM +0200, Lars Heidieker wrote:
> I don't see the need either, I can understand it from debugging
> purposes, but the stats malloc collects don't show who exactly
> allocated but only the subsystem and that information is somewhat
This is valuable information actual
On Wed, Apr 06, 2011 at 04:39:04PM +0100, Mindaugas Rasiukevicius wrote:
>
> No, I do not see the need to collect statistics about every allocation,
> e.g. load of temporary buffer, string, whatever allocations/frees.
Besides which, DTrace can *do* this. And, contrary to what I've seen in
this t
Lars Heidieker wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/02/11 02:31, Mindaugas Rasiukevicius wrote:
> >
> > I think it would be better to convert malloc(9) to kmem(9) where
> > possible before the merger. So we could better see what is left
> > i.e. what memory alloca
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/06/11 17:39, Mindaugas Rasiukevicius wrote:
> Manuel Bouyer wrote:
>> On Tue, Apr 05, 2011 at 10:37:37AM +0100, Mindaugas Rasiukevicius
>> wrote:
>>> It could be DTrace facility or some __builtin_return_address
>>> tracking to have some means e
On Wed, Apr 06, 2011 at 04:39:04PM +0100, Mindaugas Rasiukevicius wrote:
> Manuel Bouyer wrote:
> > On Tue, Apr 05, 2011 at 10:37:37AM +0100, Mindaugas Rasiukevicius wrote:
> > > It could be DTrace facility or some __builtin_return_address tracking
> > > to have some means e.g. to identify memory
Brett Lymn wrote:
> > I am not convinced about statistics point. For intensive allocations,
> > constant-sized pool_cache(9) should/would be used, where it already
> > gathers statistics. If there is some particular need for statistics,
> > one can always collect it at the caller's level. There
Manuel Bouyer wrote:
> On Tue, Apr 05, 2011 at 10:37:37AM +0100, Mindaugas Rasiukevicius wrote:
> > It could be DTrace facility or some __builtin_return_address tracking
> > to have some means e.g. to identify memory leaks when kmem(9) is used.
> >
> > I am not convinced about statistics point.
On Tue, Apr 05, 2011 at 10:37:37AM +0100, Mindaugas Rasiukevicius wrote:
>
> I am not convinced about statistics point. For intensive allocations,
> constant-sized pool_cache(9) should/would be used, where it already
> gathers statistics. If there is some particular need for statistics,
> one ca
On Tue, Apr 05, 2011 at 11:55:06AM +0200, Lars Heidieker wrote:
> On 05/04/2011 11:40, Manuel Bouyer wrote:
> >On Tue, Apr 05, 2011 at 11:26:10AM +0200, Lars Heidieker wrote:
> >>That's what I meant with the overhaul, the statistics must be per
> >>CPU then, the current statistics implementation is
On 05/04/2011 11:40, Manuel Bouyer wrote:
On Tue, Apr 05, 2011 at 11:26:10AM +0200, Lars Heidieker wrote:
That's what I meant with the overhaul, the statistics must be per
CPU then, the current statistics implementation is single threaded
(as malloc itself).
Technically it would be possible to a
On Tue, Apr 05, 2011 at 10:37:37AM +0100, Mindaugas Rasiukevicius wrote:
> It could be DTrace facility or some __builtin_return_address tracking
> to have some means e.g. to identify memory leaks when kmem(9) is used.
>
> I am not convinced about statistics point. For intensive allocations,
> con
On Tue, Apr 05, 2011 at 11:26:10AM +0200, Lars Heidieker wrote:
> That's what I meant with the overhaul, the statistics must be per
> CPU then, the current statistics implementation is single threaded
> (as malloc itself).
> Technically it would be possible to add some malloc like type
> informatio
Manuel Bouyer wrote:
> > >> Just an Idea, how about giving the kmem allocator a pool like
> > >> logging...
> > >
> > > or malloc(9)-like :)
> > >
> > :-) The trouble is large parts of the kernel are migrated to kmem
> > already and having too interfaces and two allocators is something that
> > ne
On 05/04/2011 10:45, Manuel Bouyer wrote:
On Tue, Apr 05, 2011 at 07:32:54AM +0200, Lars Heidieker wrote:
On 04/03/11 14:52, Manuel Bouyer wrote:
On Sun, Apr 03, 2011 at 02:36:37PM +0200, Lars Heidieker wrote:
On 04/03/11 01:36, Matthew Mondor wrote:
On Sat, 2 Apr 2011 11:49:14 +0200
Martin H
On Tue, Apr 05, 2011 at 07:32:54AM +0200, Lars Heidieker wrote:
> On 04/03/11 14:52, Manuel Bouyer wrote:
> > On Sun, Apr 03, 2011 at 02:36:37PM +0200, Lars Heidieker wrote:
> >> On 04/03/11 01:36, Matthew Mondor wrote:
> >>> On Sat, 2 Apr 2011 11:49:14 +0200
> >>> Martin Husemann wrote:
> >>>
> >
> :-) The trouble is large parts of the kernel are migrated to kmem
> already and having too interfaces and two allocators is something that
> needs cleanup. The malloc-type statistics would need a major overhaul
> if they are the way to go, what I doubt, as the essentially make
> malloc single th
On 04/03/11 14:52, Manuel Bouyer wrote:
> On Sun, Apr 03, 2011 at 02:36:37PM +0200, Lars Heidieker wrote:
>> On 04/03/11 01:36, Matthew Mondor wrote:
>>> On Sat, 2 Apr 2011 11:49:14 +0200
>>> Martin Husemann wrote:
>>>
On Sat, Apr 02, 2011 at 11:30:16AM +0200, Manuel Bouyer wrote:
> AFAIK
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 02:31, Mindaugas Rasiukevicius wrote:
>
> I think it would be better to convert malloc(9) to kmem(9) where
> possible before the merger. So we could better see what is left
> i.e. what memory allocations are performed from interrupt contex
On Sun, Apr 03, 2011 at 02:36:37PM +0200, Lars Heidieker wrote:
> On 04/03/11 01:36, Matthew Mondor wrote:
> > On Sat, 2 Apr 2011 11:49:14 +0200
> > Martin Husemann wrote:
> >
> >> On Sat, Apr 02, 2011 at 11:30:16AM +0200, Manuel Bouyer wrote:
> >>> AFAIK dtrace doesn't work on non-modular kernels
On 04/03/11 01:36, Matthew Mondor wrote:
> On Sat, 2 Apr 2011 11:49:14 +0200
> Martin Husemann wrote:
>
>> On Sat, Apr 02, 2011 at 11:30:16AM +0200, Manuel Bouyer wrote:
>>> AFAIK dtrace doesn't work on non-modular kernels ...
>> Nor on most of our archs, and AFAICT there is not even a document
>
On Sat, 2 Apr 2011 11:49:14 +0200
Martin Husemann wrote:
> On Sat, Apr 02, 2011 at 11:30:16AM +0200, Manuel Bouyer wrote:
> > AFAIK dtrace doesn't work on non-modular kernels ...
>
> Nor on most of our archs, and AFAICT there is not even a document
> describing the (maybe nontrivial amount of)
On 04/01/11 17:27, Christoph Egger wrote:
> On 04/01/11 08:35, Lars Heidieker wrote:
>> Hi,
>>
>> this is a part of the changes to the kernel memory management.
>> It's a changing the subr_extent to use kmem(9) instead of
>> malloc(9) essentially removing the MALLOC_TYPE from it.
>>
>> The next ste
On Sat, Apr 02, 2011 at 11:30:16AM +0200, Manuel Bouyer wrote:
> AFAIK dtrace doesn't work on non-modular kernels ...
Nor on most of our archs, and AFAICT there is not even a document
describing the (maybe nontrivial amount of) work needed to make it
work there.
Martin
On Sat, Apr 02, 2011 at 11:36:20AM +0200, Lars Heidieker wrote:
> >> being moved to kmem any way the point doesn't seem to be very strong
> to me.
> >
> > Why ? A leak is still a leak
> >
> Sure but even now we wound find a leak that happens if the memory
> comes from the kmem allocator, therefore
On 04/02/11 11:30, Manuel Bouyer wrote:
> On Sat, Apr 02, 2011 at 11:08:31AM +0200, Lars Heidieker wrote:
>> On 04/01/11 17:20, Manuel Bouyer wrote:
>>> On Fri, Apr 01, 2011 at 10:43:50AM -0400, Allen Briggs wrote:
On Fri, Apr 01, 2011 at 08:35:52AM +0200, Lars Heidieker wrote:
> this is a
On Sat, Apr 02, 2011 at 11:08:31AM +0200, Lars Heidieker wrote:
> On 04/01/11 17:20, Manuel Bouyer wrote:
> > On Fri, Apr 01, 2011 at 10:43:50AM -0400, Allen Briggs wrote:
> >> On Fri, Apr 01, 2011 at 08:35:52AM +0200, Lars Heidieker wrote:
> >>> this is a part of the changes to the kernel memory m
On 04/01/11 17:20, Manuel Bouyer wrote:
> On Fri, Apr 01, 2011 at 10:43:50AM -0400, Allen Briggs wrote:
>> On Fri, Apr 01, 2011 at 08:35:52AM +0200, Lars Heidieker wrote:
>>> this is a part of the changes to the kernel memory management.
>>> It's a changing the subr_extent to use kmem(9) instead of
On 04/02/11 02:31, Mindaugas Rasiukevicius wrote:
> Hello Lars,
>
> Lars Heidieker wrote:
>> this is a part of the changes to the kernel memory management.
>> It's a changing the subr_extent to use kmem(9) instead of malloc(9)
>> essentially removing the MALLOC_TYPE from it.
> Why start from this
Hello Lars,
Lars Heidieker wrote:
> this is a part of the changes to the kernel memory management.
> It's a changing the subr_extent to use kmem(9) instead of malloc(9)
> essentially removing the MALLOC_TYPE from it.
Why start from this end, instead of converting extent(9) uses to vmem(9)
and th
> On Fri, Apr 01, 2011 at 08:35:52AM +0200, Lars Heidieker wrote:
> > this is a part of the changes to the kernel memory management.
> > It's a changing the subr_extent to use kmem(9) instead of malloc(9)
> > essentially removing the MALLOC_TYPE from it.
>
> Are there tools for figuring out where
On Fri, Apr 01, 2011 at 10:43:50AM -0400, Allen Briggs wrote:
> On Fri, Apr 01, 2011 at 08:35:52AM +0200, Lars Heidieker wrote:
> > this is a part of the changes to the kernel memory management.
> > It's a changing the subr_extent to use kmem(9) instead of malloc(9)
> > essentially removing the MAL
On 04/01/11 08:35, Lars Heidieker wrote:
Hi,
this is a part of the changes to the kernel memory management.
It's a changing the subr_extent to use kmem(9) instead of malloc(9)
essentially removing the MALLOC_TYPE from it.
The next steps will provide the changes to the kmem(9)/pool(9) and the
po
On Fri, Apr 01, 2011 at 10:43:50AM -0400, Allen Briggs wrote:
> On Fri, Apr 01, 2011 at 08:35:52AM +0200, Lars Heidieker wrote:
> > this is a part of the changes to the kernel memory management.
> > It's a changing the subr_extent to use kmem(9) instead of malloc(9)
> > essentially removing the MAL
On Fri, Apr 01, 2011 at 08:35:52AM +0200, Lars Heidieker wrote:
> this is a part of the changes to the kernel memory management.
> It's a changing the subr_extent to use kmem(9) instead of malloc(9)
> essentially removing the MALLOC_TYPE from it.
Are there tools for figuring out where memory might
46 matches
Mail list logo
