Merge branch 'linus' into x86/urgent

include/linux/version.h

include/linux/utsrelease.h

include/linux/bounds.h

include/generated

# stgit generated dirs

patches-*

What:           /debug/pktcdvd/pktcdvd[0-7]

What:           /sys/kernel/debug/pktcdvd/pktcdvd[0-7]

Date:           Oct. 2006

KernelVersion:  2.6.20

Contact:        Thomas Maier <balagi@justmail.de>

The pktcdvd module (packet writing driver) creates

these files in debugfs:

/debug/pktcdvd/pktcdvd[0-7]/

/sys/kernel/debug/pktcdvd/pktcdvd[0-7]/

    info            (0444) Lots of driver statistics and infos.

Example:

-------

cat /debug/pktcdvd/pktcdvd0/info

cat /sys/kernel/debug/pktcdvd/pktcdvd0/info

###

# The targets that may be used.

PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs

PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs

BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))

xmldocs: $(BOOKS)

dochelp:

	@echo  ' Linux kernel internal documentation in different formats:'

	@echo  '  htmldocs        - HTML'

	@echo  '  installmandocs  - install man pages generated by mandocs'

	@echo  '  mandocs         - man pages'

	@echo  '  pdfdocs         - PDF'

	@echo  '  psdocs          - Postscript'

	@echo  '  xmldocs         - XML DocBook'

	@echo  '  mandocs         - man pages'

	@echo  '  installmandocs  - install man pages generated by mandocs'

	@echo  '  cleandocs       - clean all generated DocBook files'

###

# Temporary files left by various tools

clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man

cleandocs:

	$(Q)rm -f $(call objectify, $(clean-files))

	$(Q)rm -rf $(call objectify, $(clean-dirs))

# Declare the contents of the .PHONY variable as phony.  We keep that

# information in a variable se we can use it in if_changed and friends.

iii. Plugging the queue to batch requests in anticipation of opportunities for

     merge/sort optimizations

This is just the same as in 2.4 so far, though per-device unplugging

support is anticipated for 2.5. Also with a priority-based i/o scheduler,

such decisions could be based on request priorities.

Plugging is an approach that the current i/o scheduling algorithm resorts to so

that it collects up enough requests in the queue to be able to take

advantage of the sorting/merging logic in the elevator. If the

queue is empty when a request comes in, then it plugs the request queue

(sort of like plugging the bottom of a vessel to get fluid to build up)

(sort of like plugging the bath tub of a vessel to get fluid to build up)

till it fills up with a few more requests, before starting to service

the requests. This provides an opportunity to merge/sort the requests before

passing them down to the device. There are various conditions when the queue is

unplugged (to open up the flow again), either through a scheduled task or

could be on demand. For example wait_on_buffer sets the unplugging going

(by running tq_disk) so the read gets satisfied soon. So in the read case,

the queue gets explicitly unplugged as part of waiting for completion,

in fact all queues get unplugged as a side-effect.

through sync_buffer() running blk_run_address_space(mapping). Or the caller

can do it explicity through blk_unplug(bdev). So in the read case,

the queue gets explicitly unplugged as part of waiting for completion on that

buffer. For page driven IO, the address space ->sync_page() takes care of

doing the blk_run_address_space().

Aside:

  This is kind of controversial territory, as it's not clear if plugging is

  multi-page bios being queued in one shot, we may not need to wait to merge

  a big request from the broken up pieces coming by.

  Per-queue granularity unplugging (still a Todo) may help reduce some of the

  concerns with just a single tq_disk flush approach. Something like

  blk_kick_queue() to unplug a specific queue (right away ?)

  or optionally, all queues, is in the plan.

4.4 I/O contexts

I/O contexts provide a dynamically allocated per process data area. They may

be used in I/O schedulers, and in the block layer (could be used for IO statis,

process (bash) into it. CPU time consumed by this bash and its children

can be obtained from g1/cpuacct.usage and the same is accumulated in

/cgroups/cpuacct.usage also.

cpuacct.stat file lists a few statistics which further divide the

CPU time obtained by the cgroup into user and system times. Currently

the following statistics are supported:

user: Time spent by tasks of the cgroup in user mode.

system: Time spent by tasks of the cgroup in kernel mode.

user and system are in USER_HZ unit.

cpuacct controller uses percpu_counter interface to collect user and

system times. This has two side effects:

- It is theoretically possible to see wrong values for user and system times.

  This is because percpu_counter_read() on 32bit systems isn't safe

  against concurrent writes.

- It is possible to see slightly outdated values for user and system times

  due to the batch processing nature of percpu_counter.