Evgeniy Polyakov wrote:
On Sat, Jan 20, 2007 at 05:36:03PM -0500, Rik van Riel ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov wrote:
On Fri, Jan 19, 2007 at 01:53:15PM +0100, Peter Zijlstra
([EMAIL PROTECTED]) wrote:
Even further development of such idea is to prevent such OOM condition
at all -
> On Sat, Jan 20, 2007 at 05:36:03PM -0500, Rik van Riel ([EMAIL PROTECTED])
> wrote:
> > Due to the way everything in the kernel works, you cannot
> > prevent the memory allocator from allocating everything and
> > running out, except maybe by setting aside reserves to deal
> > with special subsy
On Sat, Jan 20, 2007 at 05:36:03PM -0500, Rik van Riel ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >On Fri, Jan 19, 2007 at 01:53:15PM +0100, Peter Zijlstra
> >([EMAIL PROTECTED]) wrote:
>
> >>>Even further development of such idea is to prevent such OOM condition
> >>>at all - by sta
Evgeniy Polyakov wrote:
On Fri, Jan 19, 2007 at 01:53:15PM +0100, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
Even further development of such idea is to prevent such OOM condition
at all - by starting swapping early (but wisely) and reduce memory
usage.
These just postpone execution but will
On Fri, Jan 19, 2007 at 01:53:15PM +0100, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> > 2. You differentiate by hand between critical and non-critical
> > allocations by specifying some kernel users as potentially possible to
> > allocate from reserve.
>
> True, all sockets that are needed for s
On Thu, 18 Jan 2007, Peter Zijlstra wrote:
>
> > Cache misses for small packet flow due to the fact, that the same data
> > is allocated and freed and accessed on different CPUs will become an
> > issue soon, not right now, since two-four core CPUs are not yet to be
> > very popular and price fo
> Let me briefly describe your approach and possible drawbacks in it.
> You start reserving some memory when systems is under memory pressure.
> when system is in real trouble, you start using that reserve for special
> tasks mainly for network path to allocate packets and process them in
> order
On Thu, Jan 18, 2007 at 06:31:53PM +0100, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> > skbs are the most extensively used path.
> > Actually the same is applied to route - dst_entries and rtable are
> > allocated through own wrappers.
>
> Still, edit all places and perhaps forget one and make s
On Thu, 2007-01-18 at 18:50 +0300, Evgeniy Polyakov wrote:
> On Thu, Jan 18, 2007 at 04:10:52PM +0100, Peter Zijlstra ([EMAIL PROTECTED])
> wrote:
> > On Thu, 2007-01-18 at 16:58 +0300, Evgeniy Polyakov wrote:
> >
> > > Network is special in this regard, since it only has one allocation path
> >
On Thu, Jan 18, 2007 at 04:10:52PM +0100, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> On Thu, 2007-01-18 at 16:58 +0300, Evgeniy Polyakov wrote:
>
> > Network is special in this regard, since it only has one allocation path
> > (actually it has one cache for skb, and usual kmalloc, but they are
>
On Thu, 2007-01-18 at 16:58 +0300, Evgeniy Polyakov wrote:
> Network is special in this regard, since it only has one allocation path
> (actually it has one cache for skb, and usual kmalloc, but they are
> called from only two functions).
>
> So it would become
> ptr = network_alloc();
> and net
On Thu, Jan 18, 2007 at 01:18:44PM +0100, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> > > How would that end up being different, I would have to replace all
> > > allocations done in the full network processing path.
> > >
> > > This seems a much less invasive method, all the (allocation) code ca
12 matches
Mail list logo
