Once we select a memory range to free, we currently block on inode
lock. Do not block and use trylock instead. And move on to next memory
range if trylock fails.
Reason being that in next few patches I want to enabling waiting for
memmory ranges to become free in fuse_iomap_begin(). So insted of
r
Memory shouldn't be freed when hardware is still running.
Signed-off-by: Andrzej Hajda
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/g
Memory shouldn't be freed when hardware is still running.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.
On Wed, Aug 20, 2014 at 01:01:19AM -0500, Christoph Lameter wrote:
> On Tue, 19 Aug 2014, Paul E. McKenney wrote:
>
> > > We could also remove the #ifdefs if init_rcu_head and destroy_rcu_head
> > > are no ops if CONFIG_DEBUG_RCU_HEAD is not defined.
> >
> > And indeed they are, good point! It ap
On Tue, 19 Aug 2014, Paul E. McKenney wrote:
> > We could also remove the #ifdefs if init_rcu_head and destroy_rcu_head
> > are no ops if CONFIG_DEBUG_RCU_HEAD is not defined.
>
> And indeed they are, good point! It appears to me that both sets of
> #ifdefs can go away.
Ok then this is a first w
On Tue, Aug 19, 2014 at 09:00:05PM -0500, Christoph Lameter wrote:
> On Mon, 18 Aug 2014, Paul E. McKenney wrote:
>
> > > +#ifdef CONFIG_RCU_DEBUG_XYZ
> >
> > If you make CONFIG_RCU_DEBUG_XYZ instead be CONFIG_DEBUG_OBJECTS_RCU_HEAD,
> > then it will automatically show up when it needs to.
>
> Ok
On Mon, 18 Aug 2014, Paul E. McKenney wrote:
> > +#ifdef CONFIG_RCU_DEBUG_XYZ
>
> If you make CONFIG_RCU_DEBUG_XYZ instead be CONFIG_DEBUG_OBJECTS_RCU_HEAD,
> then it will automatically show up when it needs to.
Ok.
> The rest looks plausible, for whatever that is worth.
We talked in the hallwa
On Mon, Aug 18, 2014 at 10:44:34PM -0500, Christoph Lameter wrote:
> On Mon, 18 Aug 2014, Paul E. McKenney wrote:
>
> > > > So call rcu activates the object, but the object has no reference in
> > > > the debug objects code so the fixup code is called which inits the
> > > > object and allocates a
On Mon, 18 Aug 2014, Paul E. McKenney wrote:
> > > So call rcu activates the object, but the object has no reference in
> > > the debug objects code so the fixup code is called which inits the
> > > object and allocates a reference
> >
> > So we need to init the object in the page struct befo
On Thu, Jun 19, 2014 at 03:19:39PM -0500, Christoph Lameter wrote:
> On Thu, 19 Jun 2014, Thomas Gleixner wrote:
>
> > Well, no. Look at the callchain:
> >
> > __call_rcu
> > debug_object_activate
> >rcuhead_fixup_activate
> > debug_object_init
> > kmem_cache_al
On Sat, Jul 12, 2014 at 02:03:57PM -0400, Sasha Levin wrote:
> On 06/20/2014 11:40 AM, Paul E. McKenney wrote:
> > rcu: Export debug_init_rcu_head() and and debug_init_rcu_head()
> >
> > Currently, call_rcu() relies on implicit allocation and initialization
> > for the debug-objects handling of RC
On 06/20/2014 11:40 AM, Paul E. McKenney wrote:
> rcu: Export debug_init_rcu_head() and and debug_init_rcu_head()
>
> Currently, call_rcu() relies on implicit allocation and initialization
> for the debug-objects handling of RCU callbacks. If you hammer the
> kernel hard enough with Sasha's modif
On Fri, Jun 20, 2014 at 10:17:32AM +0200, Thomas Gleixner wrote:
> On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> > On Thu, Jun 19, 2014 at 11:32:41PM +0200, Thomas Gleixner wrote:
> > >
> > >
> > > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> > >
> > > > On Thu, Jun 19, 2014 at 10:37:17PM +02
On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> This commit therefore exports the debug_init_rcu_head() and
> debug_rcu_head_free() functions, which permits the allocators to allocated
> and pre-initialize the debug-objects information, so that there no longer
> any need for call_rcu() to do that i
On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> On Thu, Jun 19, 2014 at 11:32:41PM +0200, Thomas Gleixner wrote:
> >
> >
> > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> >
> > > On Thu, Jun 19, 2014 at 10:37:17PM +0200, Thomas Gleixner wrote:
> > > > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
On Thu, Jun 19, 2014 at 11:32:41PM +0200, Thomas Gleixner wrote:
>
>
> On Thu, 19 Jun 2014, Paul E. McKenney wrote:
>
> > On Thu, Jun 19, 2014 at 10:37:17PM +0200, Thomas Gleixner wrote:
> > > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> > > > On Thu, Jun 19, 2014 at 09:29:08PM +0200, Thomas G
On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> On Thu, Jun 19, 2014 at 10:37:17PM +0200, Thomas Gleixner wrote:
> > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> > > On Thu, Jun 19, 2014 at 09:29:08PM +0200, Thomas Gleixner wrote:
> > > > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> > > > Wel
On Thu, Jun 19, 2014 at 04:42:11PM -0400, Sasha Levin wrote:
> On 06/19/2014 04:29 PM, Paul E. McKenney wrote:
> > rcu: Provide call_rcu_alloc() and call_rcu_sched_alloc() to avoid recursion
> >
> > The sl*b allocators use call_rcu() to manage object lifetimes, but
> > call_rcu() can use debug-obj
On Thu, Jun 19, 2014 at 10:37:17PM +0200, Thomas Gleixner wrote:
> On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> > On Thu, Jun 19, 2014 at 09:29:08PM +0200, Thomas Gleixner wrote:
> > > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> > > Well, no. Look at the callchain:
> > >
> > > __call_rcu
> >
On Thu, Jun 19, 2014 at 04:32:38PM -0400, Sasha Levin wrote:
> On 06/19/2014 04:29 PM, Paul E. McKenney wrote:
> > On Thu, Jun 19, 2014 at 09:29:08PM +0200, Thomas Gleixner wrote:
> >> > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> >> >
> >>> > > On Thu, Jun 19, 2014 at 10:03:04AM -0500, Christo
On 06/19/2014 04:29 PM, Paul E. McKenney wrote:
> rcu: Provide call_rcu_alloc() and call_rcu_sched_alloc() to avoid recursion
>
> The sl*b allocators use call_rcu() to manage object lifetimes, but
> call_rcu() can use debug-objects, which in turn invokes the sl*b
> allocators. These allocators ar
On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> On Thu, Jun 19, 2014 at 09:29:08PM +0200, Thomas Gleixner wrote:
> > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> > Well, no. Look at the callchain:
> >
> > __call_rcu
> > debug_object_activate
> >rcuhead_fixup_activate
> > deb
On Thu, Jun 19, 2014 at 03:19:39PM -0500, Christoph Lameter wrote:
> On Thu, 19 Jun 2014, Thomas Gleixner wrote:
>
> > Well, no. Look at the callchain:
> >
> > __call_rcu
> > debug_object_activate
> >rcuhead_fixup_activate
> > debug_object_init
> > kmem_cache_al
On 06/19/2014 04:29 PM, Paul E. McKenney wrote:
> On Thu, Jun 19, 2014 at 09:29:08PM +0200, Thomas Gleixner wrote:
>> > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
>> >
>>> > > On Thu, Jun 19, 2014 at 10:03:04AM -0500, Christoph Lameter wrote:
> > > On Thu, 19 Jun 2014, Sasha Levin wrote:
>>
On Thu, Jun 19, 2014 at 09:29:08PM +0200, Thomas Gleixner wrote:
> On Thu, 19 Jun 2014, Paul E. McKenney wrote:
>
> > On Thu, Jun 19, 2014 at 10:03:04AM -0500, Christoph Lameter wrote:
> > > On Thu, 19 Jun 2014, Sasha Levin wrote:
> > >
> > > > [ 690.770137] ? __this_cpu_preempt_check (lib/smp_p
On Thu, 19 Jun 2014, Christoph Lameter wrote:
> On Thu, 19 Jun 2014, Thomas Gleixner wrote:
>
> > Well, no. Look at the callchain:
> >
> > __call_rcu
> > debug_object_activate
> >rcuhead_fixup_activate
> > debug_object_init
> > kmem_cache_alloc
> >
> > So call r
On Thu, 19 Jun 2014, Thomas Gleixner wrote:
> Well, no. Look at the callchain:
>
> __call_rcu
> debug_object_activate
>rcuhead_fixup_activate
> debug_object_init
> kmem_cache_alloc
>
> So call rcu activates the object, but the object has no reference in
> the de
On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> On Thu, Jun 19, 2014 at 10:03:04AM -0500, Christoph Lameter wrote:
> > On Thu, 19 Jun 2014, Sasha Levin wrote:
> >
> > > [ 690.770137] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
> > > [ 690.770137] __slab_alloc (mm/slub.c:1732 mm/slub.c
On Thu, Jun 19, 2014 at 10:03:04AM -0500, Christoph Lameter wrote:
> On Thu, 19 Jun 2014, Sasha Levin wrote:
>
> > [ 690.770137] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
> > [ 690.770137] __slab_alloc (mm/slub.c:1732 mm/slub.c:2205 mm/slub.c:2369)
> > [ 690.770137] ? __lock_acquir
On Thu, 19 Jun 2014, Sasha Levin wrote:
> [ 690.770137] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
> [ 690.770137] __slab_alloc (mm/slub.c:1732 mm/slub.c:2205 mm/slub.c:2369)
> [ 690.770137] ? __lock_acquire (kernel/locking/lockdep.c:3189)
> [ 690.770137] ? __debug_object_init (lib
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following spew. It seems to cause an actual lockup
as hung task messages followed soon after.
[ 690.762537] =
[ 690.764196] [ INFO: possib
From: Greg KH
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Jeff Layton
commit 5cf02d09b50b1ee1c2d536c9cf64af5a7d433f56 upstream.
We've had some reports of a deadlock where rpciod ends up with a stack
trace like this:
PID: 2507 TA
From: Greg KH
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Jeff Layton
commit 5cf02d09b50b1ee1c2d536c9cf64af5a7d433f56 upstream.
We've had some reports of a deadlock where rpciod ends up with a stack
trace like this:
PID: 2507 TA
From: Greg KH
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Jeff Layton
commit 5cf02d09b50b1ee1c2d536c9cf64af5a7d433f56 upstream.
We've had some reports of a deadlock where rpciod ends up with a stack
trace like this:
PID: 2507 TA
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Jeff Layton
commit 5cf02d09b50b1ee1c2d536c9cf64af5a7d433f56 upstream.
We've had some reports of a deadlock where rpciod ends up with a stack
trace like this:
PID: 2507 TASK: 88103691
Hi.
Here are the stats:
1GB P4, 2.6.11+Suspend2 2.1.8.
Soft image size limit set to 2MB to emulate Pavel's implementation (eat
as much memory as we can).
Without patch:
Freed 16545 pages in 4000 jiffies = 16.16 MB/s
Freed 83281 pages in 14060 jiffies = 23.14 MB/s
Freed 237754 pages in 41482 j
Hi.
On Thu, 2005-03-03 at 22:26, Andrew Morton wrote:
> Nigel Cunningham <[EMAIL PROTECTED]> wrote:
> >
> > Here's a patch I've prepared which improves the speed at which memory is
> > freed prior to suspend. It should be a big gain for swsusp.
>
> Patch is simple enough but, as always, please b
Nigel Cunningham <[EMAIL PROTECTED]> wrote:
>
> Here's a patch I've prepared which improves the speed at which memory is
> freed prior to suspend. It should be a big gain for swsusp.
Patch is simple enough but, as always, please back up an optimization patch
with quantitative test results.
-
To
adjustments-old/mm/vmscan.c2005-03-03
12:04:12.0 +1100
+++ 898-swap_cluster_max_adjustments-new/mm/vmscan.c2005-03-03
11:51:00.0 +1100
@@ -73,6 +73,12 @@ struct scan_control {
unsigned int gfp_mask;
int may_writepage;
+
+ /* This context's SWAP_CL
[EMAIL PROTECTED] said:
> i am allocating some 1000 bytes of memory as folows
>
> f_malloc()
> {
> .
> for (i=1 to 10)
> {
> size = 1000;
> pAddr[i] = (unsigned long) kmalloc(size, GFP_DMA | GFP_BUFFER);
> }
> ...
> }
You don't check if you got the memory (
[EMAIL PROTECTED] writes:
> hi,
>
> i am allocating some 1000 bytes of memory as folows
>
> f_malloc()
> {
> .
> for (i=1 to 10)
> {
> size = 1000;
> pAddr[i] = (unsigned long) kmalloc(size, GFP_DMA | GFP_BUFFER);
[snip]
> pAddr is defined as 'unsigned long pAddr[
It's not a fault of kernel, it's just a mistake.
you should use
for(i=0 to 9)
pAddr[10] only has a range of 0 to 9.
miic> f_malloc()
miic> {
miic> .
miic> for (i=1 to 10)
miic> {
miic> size = 1000;
miic> pAddr[i] = (unsigned long) kmalloc(size, GFP_DMA | GFP_BUFFER);
hi,
i am allocating some 1000 bytes of memory as folows
f_malloc()
{
.
for (i=1 to 10)
{
size = 1000;
pAddr[i] = (unsigned long) kmalloc(size, GFP_DMA | GFP_BUFFER);
}
...
}
and freeing the allocated memory as follows
f_free()
{
.
for (i=1 t
43 matches
Mail list logo
