Revert "Revert avmfritz breaker"

This reverts commit 98cad59f5eb44515029178fd84c12f29f52ed7f6.

Better fix following
compiler/gcc4: Make quirk for asm_volatile_goto() unconditional

I started noticing problems with KVM guest destruction on Linux
3.12+, where guest memory wasn't being cleaned up. I bisected it
down to the commit introducing the new 'asm goto'-based atomics,
and found this quirk was later applied to those.

Unfortunately, even with GCC 4.8.2 (which ostensibly fixed the
known 'asm goto' bug) I am still getting some kind of
miscompilation. If I enable the asm_volatile_goto quirk for my
compiler, KVM guests are destroyed correctly and the memory is
cleaned up.

So make the quirk unconditional for now, until bug is found
and fixed.

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/1392274867-15236-1-git-send-email-steven@uplinklabs.net
Link: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Merge branch '3.13/misc' into 3.13/master
block: Switch from BFQ-v7 for 3.13.0 to BFQ-v7r1 for 3.13.0

In a code-cleanup phase, we introduced the following errors in the
heuristic for detecting when an application is soft real-time:
. We started (properly) to use the macro time_is_before_jiffies() to
  take wraparound issues into account, but such a macro easily returns
  anomalous results if its argument is equal to the value that we used
  as an approximation of 'infinity', namely ((unsigned long) (-1)).
  The consequence was that the logical expression used to determine
  whether a queue belongs to a soft real-time application often yielded
  an incorrect result. In the end, some application happened to be
  incorrectly deemed as soft real-time and hence weight-raised. This
  affected both throughput and latency guarantees.
. In an attempt to use the above macro in a logical expression we made a
  scriverner's error.

In addition, we realized that:
. On the expiration of a queue, the condition that allowed a
  weight-raising period to start, in case the queueu was soft
  real-time, was not the most general one. In particular, this could
  uncorrectly prevent an empty queue from being deemed as soft
  real-time.
. Jiffies-comparison macros were not used in the following cases, whereas
  they had to:
  . to establish whether an application initially deemed as interactive
    is now meeting the requirements for being classified as soft
    real-time;
  . to determine if a weight-raising period must be ended.
. The type of the time quantities used in the weight-raising heuristics
  was u64, whereas the type of the time (jiffies) is unsigned long.
. There were some typos in the wrais-related log messages.
. The next_active and active_entity field of the bfq_sched_data data
  structure did not follow the new naming convention introduced with v7.

This commit tries to address and fix all the above issues and problems.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
block: Switch from BFQ-v7r1 for 3.13.0 to BFQ-v7r2 for 3.13.0

1) BUGFIX/IMPROVEMENT. One of the requirements for an application to be
   deemed as soft real-time is that it issues its requests in batches, and
   stops doing I/O for a well-defined amount of time before issuing a new
   batch. Imposing this minimum idle time allows BFQ to filter out I/O-bound
   applications that may otherwise be incorrectly deemed as soft real-time
   (under the circumstances described in detail in the comments to the
   function bfq_bfqq_softrt_next_start()). Unfortunately, BFQ could however
   start counting this idle time from two different events: either from the
   expiration of the queue, if all requests of the queue had also been already
   completed when the queue expired, or, if the previous condition did not
   hold, from the first completion of one of the still outstanding requests.
   In the second case, an application had more chances to be deemed as soft
   real-time.
   Actually, there was no reason for this differentiated treatment. We
   addressed this issue by defining more precisely the above requirement for
   an application to be deemed as soft real-time, and changing the code
   consequently: a well-defined amount of time must elapse between the
   completion of *all the requests* of the current pending batch and the
   issuing of the first request of the next batch (this is, in the end, what
   happens with a true soft real-time application). This change further
   reduced false positives, and, as such, improved responsiveness and reduced
   latency for actual soft real-time applications.
2) CODE IMPROVEMENT. We cleaned up the code a little bit and addressed
   some issues pointed out by the checkpatch.pl script.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
Merge branch '3.13/bfq' into 3.13/master
Merge remote-tracking branch 'damentz/3.13/master' into 3.13/my