linux-stable.git/drivers/mtd/mtdcore.c, branch linux-3.7.y

Revert "revert "Revert "mm: remove __GFP_NO_KSWAPD""" and associated damage

2012-12-10T19:03:05+00:00

This reverts commits a50915394f1fc02c2861d3b7ce7014788aa5066e and
d7c3b937bdf45f0b844400b7bf6fd3ed50bac604.

This is a revert of a revert of a revert.  In addition, it reverts the
even older i915 change to stop using the __GFP_NO_KSWAPD flag due to the
original commits in linux-next.

It turns out that the original patch really was bogus, and that the
original revert was the correct thing to do after all.  We thought we
had fixed the problem, and then reverted the revert, but the problem
really is fundamental: waking up kswapd simply isn't the right thing to
do, and direct reclaim sometimes simply _is_ the right thing to do.

When certain allocations fail, we simply should try some direct reclaim,
and if that fails, fail the allocation.  That's the right thing to do
for THP allocations, which can easily fail, and the GPU allocations want
to do that too.

So starting kswapd is sometimes simply wrong, and removing the flag that
said "don't start kswapd" was a mistake.  Let's hope we never revisit
this mistake again - and certainly not this many times ;)

Acked-by: Mel Gorman 
Acked-by: Johannes Weiner 
Cc: Rik van Riel 
Cc: Andrew Morton 
Signed-off-by: Linus Torvalds

revert "Revert "mm: remove __GFP_NO_KSWAPD""

2012-11-30T16:51:17+00:00

It apepars that this patch was innocent, and we hope that "mm: avoid
waking kswapd for THP allocations when compaction is deferred or
contended" will fix the final kswapd-spinning cause.

Cc: Zdenek Kabelac 
Cc: Seth Jennings 
Cc: Valdis Kletnieks 
Cc: Jiri Slaby 
Cc: Rik van Riel 
Cc: Robert Jennings 
Cc: Mel Gorman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Revert "mm: remove __GFP_NO_KSWAPD"

2012-11-27T01:41:24+00:00

With "mm: vmscan: scale number of pages reclaimed by reclaim/compaction
based on failures" reverted, Zdenek Kabelac reported the following

  Hmm,  so it's just took longer to hit the problem and observe
  kswapd0 spinning on my CPU again - it's not as endless like before -
  but still it easily eats minutes - it helps to	turn off  Firefox
  or TB  (memory hungry apps) so kswapd0 stops soon - and restart
  those apps again.  (And I still have like >1GB of cached memory)

  kswapd0         R  running task        0    30      2 0x00000000
  Call Trace:
    preempt_schedule+0x42/0x60
    _raw_spin_unlock+0x55/0x60
    put_super+0x31/0x40
    drop_super+0x22/0x30
    prune_super+0x149/0x1b0
    shrink_slab+0xba/0x510

The sysrq+m indicates the system has no swap so it'll never reclaim
anonymous pages as part of reclaim/compaction.  That is one part of the
problem but not the root cause as file-backed pages could also be
reclaimed.

The likely underlying problem is that kswapd is woken up or kept awake
for each THP allocation request in the page allocator slow path.

If compaction fails for the requesting process then compaction will be
deferred for a time and direct reclaim is avoided.  However, if there
are a storm of THP requests that are simply rejected, it will still be
the the case that kswapd is awake for a prolonged period of time as
pgdat->kswapd_max_order is updated each time.  This is noticed by the
main kswapd() loop and it will not call kswapd_try_to_sleep().  Instead
it will loopp, shrinking a small number of pages and calling
shrink_slab() on each iteration.

The temptation is to supply a patch that checks if kswapd was woken for
THP and if so ignore pgdat->kswapd_max_order but it'll be a hack and not
backed up by proper testing.  As 3.7 is very close to release and this
is not a bug we should release with, a safer path is to revert "mm:
remove __GFP_NO_KSWAPD" for now and revisit it with the view to ironing
out the balance_pgdat() logic in general.

Signed-off-by: Mel Gorman 
Cc: Zdenek Kabelac 
Cc: Seth Jennings 
Cc: Valdis Kletnieks 
Cc: Jiri Slaby 
Cc: Rik van Riel 
Cc: Robert Jennings 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge tag 'disintegrate-mtd-20121009' of git://git.infradead.org/users/dhowells/linux-headers

2012-10-09T14:04:25+00:00

UAPI Disintegration 2012-10-09

Conflicts:
	MAINTAINERS
	arch/arm/configs/bcmring_defconfig
	arch/arm/mach-imx/clk-imx51-imx53.c
	drivers/mtd/nand/Kconfig
	drivers/mtd/nand/bcm_umi_nand.c
	drivers/mtd/nand/nand_bcm_umi.h
	drivers/mtd/nand/orion_nand.c

mm: remove __GFP_NO_KSWAPD

2012-10-09T07:22:15+00:00

When transparent huge pages were introduced, memory compaction and swap
storms were an issue, and the kernel had to be careful to not make THP
allocations cause pageout or compaction.

Now that we have working compaction deferral, kswapd is smart enough to
invoke compaction and the quadratic behaviour around isolate_free_pages
has been fixed, it should be safe to remove __GFP_NO_KSWAPD.

[minchan@kernel.org: Comment fix]
[mgorman@suse.de: Avoid direct reclaim for deferred compaction]
Cc: Andrea Arcangeli 
Signed-off-by: Rik van Riel 
Signed-off-by: Mel Gorman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mtd: check for max_bitflips in mtd_read_oob()

2012-09-29T13:50:50+00:00

mtd_read_oob() has some unexpected similarities to mtd_read(). For
instance, when ops->datbuf != NULL, nand_base.c might return max_bitflips;
however, when ops->datbuf == NULL, nand_base's code potentially could
return -EUCLEAN (no in-tree drivers do this yet). In any case where the
driver might return max_bitflips, we should translate this into an
appropriate return code using the bitflip_threshold.

Essentially, mtd_read_oob() duplicates the logic from mtd_read().

This prevents users of mtd_read_oob() from receiving a positive return
value (i.e., from max_bitflips) and interpreting it as an unknown error.

Artem: amend comments.

Signed-off-by: Brian Norris 
Reviewed-by: Mike Dunn 
Reviewed-by: Shmulik Ladkani 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: David Woodhouse

mtd: move mtd_read_oob() definition out of mtd.h

2012-07-06T17:16:24+00:00

mtd_read_oob() will be expanded a little, so don't leave it in the header
as a static inline function.

Signed-off-by: Brian Norris 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: David Woodhouse

mtd: driver _read() returns max_bitflips; mtd_read() returns -EUCLEAN

2012-05-14T04:14:23+00:00

The drivers' _read() method, absent an error, returns a non-negative integer
indicating the maximum number of bit errors that were corrected in any one
region comprising an ecc step.  MTD returns -EUCLEAN if this is >=
bitflip_threshold, 0 otherwise.  If bitflip_threshold is zero, the comparison is
not made since these devices lack ECC and always return zero in the non-error
case (thanks Brian)¹.  Note that this is a subtle change to the driver
interface.

This and the preceding patches in this set were tested with ubi on top of the
nandsim and docg4 devices, running the ubi test io_basic from mtd-utils.

¹ http://lists.infradead.org/pipermail/linux-mtd/2012-March/040468.html

Signed-off-by: Mike Dunn 
Acked-by: Robert Jarzmik 
Acked-by: Brian Norris 
Ivan Djelic 
Signed-off-by: Artem Bityutskiy 

Signed-off-by: David Woodhouse

mtd: bitflip_threshold added to mtd_info and sysfs

2012-05-14T04:11:39+00:00

An element 'bitflip_threshold' is added to struct mtd_info, and also exposed as
a read/write variable in sysfs.  This will be used to determine whether or not
mtd_read() returns -EUCLEAN or 0 (absent a hard error).  If the driver leaves it
as zero, mtd will set it to a default value of ecc_strength.

This v2 adds the line that propagates bitflip_threshold from the master to the
partitions - thanks Ivan¹.

¹ http://lists.infradead.org/pipermail/linux-mtd/2012-April/040900.html

Signed-off-by: Mike Dunn 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: David Woodhouse

mtd: expose ecc_strength through sysfs

2012-05-14T04:10:45+00:00

ecc_strength element of struct mtd_info is exposed as a read-only variable in
sysfs.

Signed-off-by: Mike Dunn 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: David Woodhouse