Merge tag 'mac80211-next-for-davem-2016-02-26' into next2

For details to this subsystem look at Documentation/rfkill.txt.

What:		/sys/class/rfkill/rfkill[0-9]+/state

Date:		09-Jul-2007

KernelVersion	v2.6.22

Contact:	linux-wireless@vger.kernel.org

Description: 	Current state of the transmitter.

		This file is deprecated and scheduled to be removed in 2014,

		because its not possible to express the 'soft and hard block'

		state of the rfkill driver.

Values: 	A numeric value.

		0: RFKILL_STATE_SOFT_BLOCKED

			transmitter is turned off by software

		1: RFKILL_STATE_UNBLOCKED

			transmitter is (potentially) active

		2: RFKILL_STATE_HARD_BLOCKED

			transmitter is forced off by something outside of

			the driver's control.

What:		/sys/class/rfkill/rfkill[0-9]+/claim

Date:		09-Jul-2007

KernelVersion	v2.6.22

Contact:	linux-wireless@vger.kernel.org

Description:	This file is deprecated because there no longer is a way to

Description:	This file was deprecated because there no longer was a way to

		claim just control over a single rfkill instance.

		This file is scheduled to be removed in 2012.

		This file was scheduled to be removed in 2012, and was removed

		in 2016.

Values: 	0: Kernel handles events

For details to this subsystem look at Documentation/rfkill.txt.

For the deprecated /sys/class/rfkill/*/state and

/sys/class/rfkill/*/claim knobs of this interface look in

Documentation/ABI/obsolete/sysfs-class-rfkill.

For the deprecated /sys/class/rfkill/*/claim knobs of this interface look in

Documentation/ABI/removed/sysfs-class-rfkill.

What: 		/sys/class/rfkill

Date:		09-Jul-2007

		1: true

What:		/sys/class/rfkill/rfkill[0-9]+/state

Date:		09-Jul-2007

KernelVersion	v2.6.22

Contact:	linux-wireless@vger.kernel.org

Description: 	Current state of the transmitter.

		This file was scheduled to be removed in 2014, but due to its

		large number of users it will be sticking around for a bit

		longer. Despite it being marked as stabe, the newer "hard" and

		"soft" interfaces should be preffered, since it is not possible

		to express the 'soft and hard block' state of the rfkill driver

		through this interface. There will likely be another attempt to

		remove it in the future.

Values: 	A numeric value.

		0: RFKILL_STATE_SOFT_BLOCKED

			transmitter is turned off by software

		1: RFKILL_STATE_UNBLOCKED

			transmitter is (potentially) active

		2: RFKILL_STATE_HARD_BLOCKED

			transmitter is forced off by something outside of

			the driver's control.

What:		/sys/class/rfkill/rfkill[0-9]+/hard

Date:		12-March-2010

KernelVersion	v2.6.34

	- Network priority cgroups details and usages.

pids.txt

	- Process number cgroups details and usages.

resource_counter.txt

	- Resource Counter API.

unified-hierarchy.txt

	- Description the new/next cgroup interface.

- Run dd to read a file and see if rate is throttled to 1MB/s or not.

		# dd if=/mnt/common/zerofile of=/dev/null bs=4K count=1024

		# iflag=direct

        # dd iflag=direct if=/mnt/common/zerofile of=/dev/null bs=4K count=1024

        1024+0 records in

        1024+0 records out

        4194304 bytes (4.2 MB) copied, 4.0001 s, 1.0 MB/s

groups and put applications in that group which are not driving enough

IO to keep disk busy. In that case set group_idle=0, and CFQ will not idle

on individual groups and throughput should improve.

Writeback

=========

Page cache is dirtied through buffered writes and shared mmaps and

written asynchronously to the backing filesystem by the writeback

mechanism.  Writeback sits between the memory and IO domains and

regulates the proportion of dirty memory by balancing dirtying and

write IOs.

On traditional cgroup hierarchies, relationships between different

controllers cannot be established making it impossible for writeback

to operate accounting for cgroup resource restrictions and all

writeback IOs are attributed to the root cgroup.

If both the blkio and memory controllers are used on the v2 hierarchy

and the filesystem supports cgroup writeback, writeback operations

correctly follow the resource restrictions imposed by both memory and

blkio controllers.

Writeback examines both system-wide and per-cgroup dirty memory status

and enforces the more restrictive of the two.  Also, writeback control

parameters which are absolute values - vm.dirty_bytes and

vm.dirty_background_bytes - are distributed across cgroups according

to their current writeback bandwidth.

There's a peculiarity stemming from the discrepancy in ownership

granularity between memory controller and writeback.  While memory

controller tracks ownership per page, writeback operates on inode

basis.  cgroup writeback bridges the gap by tracking ownership by

inode but migrating ownership if too many foreign pages, pages which

don't match the current inode ownership, have been encountered while

writing back the inode.

This is a conscious design choice as writeback operations are

inherently tied to inodes making strictly following page ownership

complicated and inefficient.  The only use case which suffers from

this compromise is multiple cgroups concurrently dirtying disjoint

regions of the same inode, which is an unlikely use case and decided

to be unsupported.  Note that as memory controller assigns page

ownership on the first use and doesn't update it until the page is

released, even if cgroup writeback strictly follows page ownership,

multiple cgroups dirtying overlapping areas wouldn't work as expected.

In general, write-sharing an inode across multiple cgroups is not well

supported.

Filesystem support for cgroup writeback

---------------------------------------

A filesystem can make writeback IOs cgroup-aware by updating

address_space_operations->writepage[s]() to annotate bio's using the

following two functions.

* wbc_init_bio(@wbc, @bio)

  Should be called for each bio carrying writeback data and associates

  the bio with the inode's owner cgroup.  Can be called anytime

  between bio allocation and submission.

* wbc_account_io(@wbc, @page, @bytes)

  Should be called for each data segment being written out.  While

  this function doesn't care exactly when it's called during the

  writeback session, it's the easiest and most natural to call it as

  data segments are added to a bio.

With writeback bio's annotated, cgroup support can be enabled per

super_block by setting MS_CGROUPWB in ->s_flags.  This allows for

selective disabling of cgroup writeback support which is helpful when

certain filesystem features, e.g. journaled data mode, are

incompatible.

wbc_init_bio() binds the specified bio to its cgroup.  Depending on

the configuration, the bio may be executed at a lower priority and if

the writeback session is holding shared resources, e.g. a journal

entry, may lead to priority inversion.  There is no one easy solution

for the problem.  Filesystems can try to work around specific problem

cases by skipping wbc_init_bio() or using bio_associate_blkcg()

directly.