Archive for the ‘Linux’ Category

IBM making moves towards private cloud with Tivoli Updates

Carl Brooks of searchCloudComputing.com just put out an interesting piece on IBM’s updating as Tivoli as a complement and perhaps a replacement for VMware in the building of private clouds. The industry seems to be taking some notice of IBM’s approach to the cloud, finally.

IBM

 

Did IBM just change the game in private cloud?

By Carl Brooks, Senior Technology Writer

02 Mar 2011 | searchCloudComputing.com

Does IBM have the wherewithal to compete in the commodity hardware cloud?

Say “IBM” and “cloud computing” in the same breath and many IT managers will roll their eyes. The IT leader’s cloud strategy has been seen by many as a mess.

But that may be about to change. IBM recently revealed a beta program of updates to its Tivoli software that may breathe new life into the company’s private cloud ambitions.

The new capabilities include support for VMware’s VIM APIs in a variety of Tivoli tools, including image repositories, automated provisioning, application deployment and Tivoli Storage Manager (integrating TSM and VMware heretofore has not been pretty). Enhancements to Tivoli Provisioning Manager may include booting VMware images directly from block storage instead of having them preloaded into memory. IBM claims that images can be booted in seconds.

Read the rest here.

Carl Brooks is the Senior Technology Writer for SearchCloudComputing.com. Contact him at cbrooks@techtarget.com.

 

Tags: , , , , , , ,


And then a miracle occurs…

Miracle

While this item is way below the clouds, every so often a piece of the programmer’s art comes along that just takes your breath away.  The kernel scheduling routine has been open now for decades, with thousands of eyeballs trying to take it to the next level – and in many cases doing so!  This is some darn good code already.  Then along comes an offhand comment from Linus, and Mike Galbraith puts out with 233 lines of code that:

                • Drops maximum latency dropping by over ten times, and
                • average latency of the desktop by about 60 times

233 line kernel patch, that yields a 60 fold performance improvement in something as fundamental as screen latency in the Linux kernel?  Unbelievable. As of 20 October 2010, when Linux 2.6.36 was last released, it had about 13,499,457 lines of code.  We are talking a 233 line patch here!

If this little corner of the tech world has room to improve  like that, it gives me hope that we have a 100+ year run of taking the broadest interpretations of Moore’s law to places as yet undreamed of.

In honor of Mike’s work, here is the current patch code, in all its raw beauty.  Tomorrow, I go find a nice tech stock and buy 100 shares, this gives me some real joy.  Long live C.

————————————–

Signed-off-by: Mike Galbraith <efault@gmx.de>

---
 Documentation/kernel-parameters.txt |    2
 drivers/tty/tty_io.c                |    1
 include/linux/sched.h               |   19 ++++
 init/Kconfig                        |   12 +++
 kernel/fork.c                       |    5 +
 kernel/sched.c                      |   25 ++++--
 kernel/sched_autogroup.c            |  140 ++++++++++++++++++++++++++++++++++++
 kernel/sched_autogroup.h            |   18 ++++
 kernel/sysctl.c                     |   11 ++
 9 files changed, 224 insertions(+), 9 deletions(-)

Index: linux-2.6/include/linux/sched.h
===================================================================
--- linux-2.6.orig/include/linux/sched.h
+++ linux-2.6/include/linux/sched.h
@@ -509,6 +509,8 @@ struct thread_group_cputimer {
 	spinlock_t lock;
 };

+struct autogroup;
+
 /*
  * NOTE! "signal_struct" does not have it's own
  * locking, because a shared signal_struct always
@@ -576,6 +578,9 @@ struct signal_struct {

 	struct tty_struct *tty; /* NULL if no tty */

+#ifdef CONFIG_SCHED_AUTOGROUP
+	struct autogroup *autogroup;
+#endif
 	/*
 	 * Cumulative resource counters for dead threads in the group,
 	 * and for reaped dead child processes forked by this group.
@@ -1931,6 +1936,20 @@ int sched_rt_handler(struct ctl_table *t

 extern unsigned int sysctl_sched_compat_yield;

+#ifdef CONFIG_SCHED_AUTOGROUP
+extern unsigned int sysctl_sched_autogroup_enabled;
+
+extern void sched_autogroup_create_attach(struct task_struct *p);
+extern void sched_autogroup_detach(struct task_struct *p);
+extern void sched_autogroup_fork(struct signal_struct *sig);
+extern void sched_autogroup_exit(struct signal_struct *sig);
+#else
+static inline void sched_autogroup_create_attach(struct task_struct *p) { }
+static inline void sched_autogroup_detach(struct task_struct *p) { }
+static inline void sched_autogroup_fork(struct signal_struct *sig) { }
+static inline void sched_autogroup_exit(struct signal_struct *sig) { }
+#endif
+
 #ifdef CONFIG_RT_MUTEXES
 extern int rt_mutex_getprio(struct task_struct *p);
 extern void rt_mutex_setprio(struct task_struct *p, int prio);
Index: linux-2.6/kernel/sched.c
===================================================================
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -78,6 +78,7 @@

 #include "sched_cpupri.h"
 #include "workqueue_sched.h"
+#include "sched_autogroup.h"

 #define CREATE_TRACE_POINTS
 #include <trace/events/sched.h>
@@ -605,11 +606,14 @@ static inline int cpu_of(struct rq *rq)
  */
 static inline struct task_group *task_group(struct task_struct *p)
 {
+	struct task_group *tg;
 	struct cgroup_subsys_state *css;

 	css = task_subsys_state_check(p, cpu_cgroup_subsys_id,
 			lockdep_is_held(&task_rq(p)->lock));
-	return container_of(css, struct task_group, css);
+	tg = container_of(css, struct task_group, css);
+
+	return autogroup_task_group(p, tg);
 }

 /* Change a task's cfs_rq and parent entity if it moves across CPUs/groups */
@@ -2006,6 +2010,7 @@ static void sched_irq_time_avg_update(st
 #include "sched_idletask.c"
 #include "sched_fair.c"
 #include "sched_rt.c"
+#include "sched_autogroup.c"
 #include "sched_stoptask.c"
 #ifdef CONFIG_SCHED_DEBUG
 # include "sched_debug.c"
@@ -7979,7 +7984,7 @@ void __init sched_init(void)
 #ifdef CONFIG_CGROUP_SCHED
 	list_add(&init_task_group.list, &task_groups);
 	INIT_LIST_HEAD(&init_task_group.children);
-
+	autogroup_init(&init_task);
 #endif /* CONFIG_CGROUP_SCHED */

 #if defined CONFIG_FAIR_GROUP_SCHED && defined CONFIG_SMP
@@ -8509,15 +8514,11 @@ void sched_destroy_group(struct task_gro
 /* change task's runqueue when it moves between groups.
  *	The caller of this function should have put the task in its new group
  *	by now. This function just updates tsk->se.cfs_rq and tsk->se.parent to
- *	reflect its new group.
+ *	reflect its new group.  Called with the runqueue lock held.
  */
-void sched_move_task(struct task_struct *tsk)
+void __sched_move_task(struct task_struct *tsk, struct rq *rq)
 {
 	int on_rq, running;
-	unsigned long flags;
-	struct rq *rq;
-
-	rq = task_rq_lock(tsk, &flags);

 	running = task_current(rq, tsk);
 	on_rq = tsk->se.on_rq;
@@ -8538,7 +8539,15 @@ void sched_move_task(struct task_struct
 		tsk->sched_class->set_curr_task(rq);
 	if (on_rq)
 		enqueue_task(rq, tsk, 0);
+}

+void sched_move_task(struct task_struct *tsk)
+{
+	struct rq *rq;
+	unsigned long flags;
+
+	rq = task_rq_lock(tsk, &flags);
+	__sched_move_task(tsk, rq);
 	task_rq_unlock(rq, &flags);
 }
 #endif /* CONFIG_CGROUP_SCHED */
Index: linux-2.6/kernel/fork.c
===================================================================
--- linux-2.6.orig/kernel/fork.c
+++ linux-2.6/kernel/fork.c
@@ -174,8 +174,10 @@ static inline void free_signal_struct(st

 static inline void put_signal_struct(struct signal_struct *sig)
 {
-	if (atomic_dec_and_test(&sig->sigcnt))
+	if (atomic_dec_and_test(&sig->sigcnt)) {
+		sched_autogroup_exit(sig);
 		free_signal_struct(sig);
+	}
 }

 void __put_task_struct(struct task_struct *tsk)
@@ -904,6 +906,7 @@ static int copy_signal(unsigned long clo
 	posix_cpu_timers_init_group(sig);

 	tty_audit_fork(sig);
+	sched_autogroup_fork(sig);

 	sig->oom_adj = current->signal->oom_adj;
 	sig->oom_score_adj = current->signal->oom_score_adj;
Index: linux-2.6/drivers/tty/tty_io.c
===================================================================
--- linux-2.6.orig/drivers/tty/tty_io.c
+++ linux-2.6/drivers/tty/tty_io.c
@@ -3160,6 +3160,7 @@ static void __proc_set_tty(struct task_s
 	put_pid(tsk->signal->tty_old_pgrp);
 	tsk->signal->tty = tty_kref_get(tty);
 	tsk->signal->tty_old_pgrp = NULL;
+	sched_autogroup_create_attach(tsk);
 }

 static void proc_set_tty(struct task_struct *tsk, struct tty_struct *tty)
Index: linux-2.6/kernel/sched_autogroup.h
===================================================================
--- /dev/null
+++ linux-2.6/kernel/sched_autogroup.h
@@ -0,0 +1,18 @@
+#ifdef CONFIG_SCHED_AUTOGROUP
+
+static void __sched_move_task(struct task_struct *tsk, struct rq *rq);
+
+static inline struct task_group *
+autogroup_task_group(struct task_struct *p, struct task_group *tg);
+
+#else /* !CONFIG_SCHED_AUTOGROUP */
+
+static inline void autogroup_init(struct task_struct *init_task) {  }
+
+static inline struct task_group *
+autogroup_task_group(struct task_struct *p, struct task_group *tg)
+{
+	return tg;
+}
+
+#endif /* CONFIG_SCHED_AUTOGROUP */
Index: linux-2.6/kernel/sched_autogroup.c
===================================================================
--- /dev/null
+++ linux-2.6/kernel/sched_autogroup.c
@@ -0,0 +1,140 @@
+#ifdef CONFIG_SCHED_AUTOGROUP
+
+unsigned int __read_mostly sysctl_sched_autogroup_enabled = 1;
+
+struct autogroup {
+	struct kref		kref;
+	struct task_group	*tg;
+};
+
+static struct autogroup autogroup_default;
+
+static void autogroup_init(struct task_struct *init_task)
+{
+	autogroup_default.tg = &init_task_group;
+	kref_init(&autogroup_default.kref);
+	init_task->signal->autogroup = &autogroup_default;
+}
+
+static inline void autogroup_destroy(struct kref *kref)
+{
+	struct autogroup *ag = container_of(kref, struct autogroup, kref);
+	struct task_group *tg = ag->tg;
+
+	kfree(ag);
+	sched_destroy_group(tg);
+}
+
+static inline void autogroup_kref_put(struct autogroup *ag)
+{
+	kref_put(&ag->kref, autogroup_destroy);
+}
+
+static inline struct autogroup *autogroup_kref_get(struct autogroup *ag)
+{
+	kref_get(&ag->kref);
+	return ag;
+}
+
+static inline struct autogroup *autogroup_create(void)
+{
+	struct autogroup *ag = kmalloc(sizeof(*ag), GFP_KERNEL);
+
+	if (!ag)
+		goto out_fail;
+
+	ag->tg = sched_create_group(&init_task_group);
+	kref_init(&ag->kref);
+
+	if (!(IS_ERR(ag->tg)))
+		return ag;
+
+out_fail:
+	if (ag) {
+		kfree(ag);
+		WARN_ON(1);
+	} else
+		WARN_ON(1);
+
+	return autogroup_kref_get(&autogroup_default);
+}
+
+static inline struct task_group *
+autogroup_task_group(struct task_struct *p, struct task_group *tg)
+{
+	int enabled = ACCESS_ONCE(sysctl_sched_autogroup_enabled);
+
+	enabled &= (tg == &root_task_group);
+	enabled &= (p->sched_class == &fair_sched_class);
+	enabled &= (!(p->flags & PF_EXITING));
+
+	if (enabled)
+		return p->signal->autogroup->tg;
+
+	return tg;
+}
+
+static void
+autogroup_move_group(struct task_struct *p, struct autogroup *ag)
+{
+	struct autogroup *prev;
+	struct task_struct *t;
+	struct rq *rq;
+	unsigned long flags;
+
+	rq = task_rq_lock(p, &flags);
+	prev = p->signal->autogroup;
+	if (prev == ag) {
+		task_rq_unlock(rq, &flags);
+		return;
+	}
+
+	p->signal->autogroup = autogroup_kref_get(ag);
+	__sched_move_task(p, rq);
+	task_rq_unlock(rq, &flags);
+
+	rcu_read_lock();
+	list_for_each_entry_rcu(t, &p->thread_group, thread_group) {
+		sched_move_task(t);
+	}
+	rcu_read_unlock();
+
+	autogroup_kref_put(prev);
+}
+
+void sched_autogroup_create_attach(struct task_struct *p)
+{
+	struct autogroup *ag = autogroup_create();
+
+	autogroup_move_group(p, ag);
+	/* drop extra refrence added by autogroup_create() */
+	autogroup_kref_put(ag);
+}
+EXPORT_SYMBOL(sched_autogroup_create_attach);
+
+/* currently has no users */
+void sched_autogroup_detach(struct task_struct *p)
+{
+	autogroup_move_group(p, &autogroup_default);
+}
+EXPORT_SYMBOL(sched_autogroup_detach);
+
+void sched_autogroup_fork(struct signal_struct *sig)
+{
+	sig->autogroup = autogroup_kref_get(current->signal->autogroup);
+}
+
+void sched_autogroup_exit(struct signal_struct *sig)
+{
+	autogroup_kref_put(sig->autogroup);
+}
+
+static int __init setup_autogroup(char *str)
+{
+	sysctl_sched_autogroup_enabled = 0;
+
+	return 1;
+}
+
+__setup("noautogroup", setup_autogroup);
+#endif
Index: linux-2.6/kernel/sysctl.c
===================================================================
--- linux-2.6.orig/kernel/sysctl.c
+++ linux-2.6/kernel/sysctl.c
@@ -382,6 +382,17 @@ static struct ctl_table kern_table[] = {
 		.mode		= 0644,
 		.proc_handler	= proc_dointvec,
 	},
+#ifdef CONFIG_SCHED_AUTOGROUP
+	{
+		.procname	= "sched_autogroup_enabled",
+		.data		= &sysctl_sched_autogroup_enabled,
+		.maxlen		= sizeof(unsigned int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+		.extra1		= &zero,
+		.extra2		= &one,
+	},
+#endif
 #ifdef CONFIG_PROVE_LOCKING
 	{
 		.procname	= "prove_locking",
Index: linux-2.6/init/Kconfig
===================================================================
--- linux-2.6.orig/init/Kconfig
+++ linux-2.6/init/Kconfig
@@ -728,6 +728,18 @@ config NET_NS

 endif # NAMESPACES

+config SCHED_AUTOGROUP
+	bool "Automatic process group scheduling"
+	select CGROUPS
+	select CGROUP_SCHED
+	select FAIR_GROUP_SCHED
+	help
+	  This option optimizes the scheduler for common desktop workloads by
+	  automatically creating and populating task groups.  This separation
+	  of workloads isolates aggressive CPU burners (like build jobs) from
+	  desktop applications.  Task group autogeneration is currently based
+	  upon task tty association.
+
 config MM_OWNER
 	bool

Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -1622,6 +1622,8 @@ and is between 256 and 4096 characters.
 	noapic		[SMP,APIC] Tells the kernel to not make use of any
 			IOAPICs that may be present in the system.

+	noautogroup	Disable scheduler automatic task group creation.
+
 	nobats		[PPC] Do not use BATs for mapping kernel lowmem
 			on "Classic" PPC cores.

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

Read more about it here.

Tags: , , ,


Intel and the G-Dudes Publish the Hype Around Cloud 2010

Cloud Computing H-cycle july 2010 (c) Gartner Inc.

Intel recently worked out deal with Gartner Inc. which allows them to post one one of their most the up to date and detailed version of the famous Gartner  Hype Cycle as relates to Cloud Computing.  You can find the file here:

http://premierit.intel.com/servlet/JiveServlet/download/5910-1-4916/Hype%20Cycle%20for%20Cloud%20Computing%2C%202010.pdf

The analysis reminds me a bit of Carl Pagans famous old saw “extraordinary claims require extraordinary evidence.”  In the cloud hype world, I think this means that the hype is deep and long, but the potential is extraordinary.  Not how much already has been on, and they claim were are just at the peak.  As an aside, the analysts do a nice job with definitions of terms.

This little fellow is (c) Gartner Inc., so you will need to download it right from Intel’s site to have a closer look.

Tags: , , , , , , ,


Xen 4.0 arrives, fault-tolerance capabilities for high rel now on board standard

By: Jeffrey Burt // e-week

2010-04-13

———————————

Xen.org is unveiling the latest release of its open-source Xen hypervisor, boosting the performance, scalability and availability of the virtualization technology.

Xen 4.0, introduced April 13, offers a host of new features designed to address demands coming from enterprises and the growth of cloud computing, according to Ian Pratt, founder and chairman of Xen.org.

Included in the more than 30 new features are fault-tolerance capabilities. Xen, like other virtualization hypervisors, enabled businesses to migrate virtual machines from one physical server to another for planned outages. However, it became more problematic when the outages were unplanned, Pratt said.

The new fault-tolerant feature enables a VM on one physical machine to be mirrored by a VM on another physical server, he said. Should one physical server go down, then the backup VM on the second server would continue running the workload with no interruption from the user’s perspective.

“The new thing here is to … have the ability to keep a second VM in sync,” Pratt said in an interview. “[In the event of an outage], everything just seamlessly switches over to the other machine.”

Many of the high-end databases and similar applications designed for clustered environments have some degree of protection, he said. However, the fault-tolerance capabilities in Xen 4.0 could help with other applications, such as typical e-mail servers.

The enhanced hypervisor also includes support for the myriad RAS (reliability, availability and serviceability) features in Intel’s high-end Xeon 7500 “Nehalem EX” processors and Advanced Micro Devices’ Opteron 6000 “Magny-Cours” chips, Pratt said.

Both processor families, introduced in late March, are the highest-performing x86 processors unveiled by the chip makers. Intel officials have said they are aiming their four- to eight-core processors at the high end of the server market, targeting workloads that traditionally have run on RISC systems or mainframes.

Contributing are the more than 20 RAS features inside the Xeon 7500 chips that until now were normally found in RISC processors, including MCA Recovery error correction, aimed at reducing data corruption and improving reliability.

Xen 4.0 support of the RAS features in the new chip platforms comes from Xen.org’s close working relationship with the chip vendors, Pratt said. The group talks with chip and chipset makers, as well as OEMs, about what it would like to see in hardware five years out to dovetail with what is being done with Xen, he said.

Xen 4.0, through its NetChannel2 feature, also takes advantage of the smart NICs (network interface cards) that are being built to create virtualized environments that offer improved data processing capabilities. At the Intel Developer Forum in September 2009, Intel and Citrix Systems set up a demonstration showing high levels of network traffic coming into a VM running on Xen, something that could not have been done without smart NICs, Pratt said.

Being able to run such network-intensive and latency-sensitive applications means that essentially any workload can run in a virtualized environment, he said.

“Now it’s almost possible to say that there are no apps out there that are not good for virtualization,” Pratt said. “Now you can look at everything in the data center [as candidates for VMs].”

Xen 4.0 also includes a number of new memory enhancements, such as Transcendent Memory, which removes the pitfalls inherent when guest operating systems use spare memory available on physical servers, he said.

Before, the nature of the spare memory was hidden from the guest OS, so if the other software needed that memory, performance would nosedive.

With Transcendent Memory, the use of the spare memory is more upfront, letting IT administrators know, for example, if the memory has been used in a dynamic fashion, and letting them decide whether they want to try to use that memory.

A full list of the features in Xen 4.0 can be found at the Xen Community Website.

Pratt said along with the new features in Xen 4.0, the Xen Community and other open-source projects have spent the past year looking to make the Xen hypervisor platform more standardized in two areas—desktops and laptops, and cloud computing.

The goal is to create Xen-based turnkey offerings with a more complete and standard software stack that businesses can more easily implement, he said.

Read more here.

Tags: , , , , , , , ,


Zend Teams With Microsoft, IBM, Gogrid, Rackspace, and others on Open Source Cloud Project

Wouldn’t it be great if all these guys really did open source cloud control api at this early stage in the evolution of the technology?

“Zend Technologies, in association with IBM, Microsoft and others, has launched the Simple API for Cloud Application Services project, an open-source initiative that enables developers to use common application services in the cloud, while enabling them to unlock value-added features available from individual providers.

Zend Technologies, in association with IBM, Microsoft and others, has launched the Simple API for Cloud Application Services project, a new open-source initiative that enables developers to use common application services in the cloud, while enabling them to unlock value-added features available from individual providers.

Zend officials said the Simple Cloud API project aims to facilitate the development of cloud applications that can access services on all major cloud platforms. Zend, IBM, Microsoft, Nirvanix, Rackspace and GoGrid are co-founding contributors to this community project. However, cloud giants such as Amazon and Google are not.

The Simple Cloud API project empowers developers to use one interface to interact with a variety of cloud application services, enabling them to more easily access new technologies from cloud vendors, said Dirk Nicol, director of emerging technology in IBM’s Software Group.

“Today developers have to write to a proprietary API, but with this Simple API you’ll have a common API that would work across vendors,” Nicol said. “It’s about portability and avoiding vendor lock-in. And this supports both public and private clouds.”

Check out more here.

Tags: , , , , , , , , , , ,


Application and Server Virtualization: Better Together, says Citrix

While many IT organizations successfully deploy virtualization, some hesitate to deploy application and server virtualization together. Learn how these virtualization technologies are complementary and how they can enhance each others’ capabilities, while having a greater positive impact on IT and the business by enabling server consolidation and improving application availability.

My friend Eric thinks these Xen/Citrix dudes are going to take over the lead in the virtual world.  He could be right.

Read the full white paper here.

- Michael Grollman

Tags: , , ,


Disaster-Proof Virtualization on a Dime with VM/VMI

Kevin Fogarty did a cool piece on budget-driven disaster recovery for a small firm in South Carolina.  There’s a lot of stuff I like in the piece, including how these guys did it with a MS-CRM application running on top of a solid Linux HA system.  But one quote that jumped out in particular was from Bob O’Donnell, on how to make

I Like Ike

I Like Ike

“That would be a sticking point, but virtual desktop migrations almost always come in stages,” according to Bob O’Donnell, an analyst specializing in client and display technologies for IDC. “It would be ideal to be able to make the leap to VDI all at once, but the practical realities of finance and maintaining operations while you’re migrating often preclude that.”

Phasing in to VM/Servers and then later VMI/Desktops & Apps, that sounds like good practical advice for most firms, despite the temptation  to make the leap all at once.

Read more here.

Tags: ,