linux-kernel - Re: [PATCH 1/4] fastboot: Asynchronous function calls to speed up kernel boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87k59aops9.fsf@basil.nowhere.org>
Date:	Sun, 04 Jan 2009 20:05:26 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	mingo@...e.hu, fweisbec@...il.com, linux-scsi@...r.kernel.org,
	linux-ide@...r.kernel.org, linux-acpi@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH 1/4] fastboot: Asynchronous function calls to speed up kernel boot

Arjan van de Ven <arjan@...radead.org> writes:
> +static int async_manager_thread(void *unused)
> +{
> +	int max_threads;
> +	DECLARE_WAITQUEUE(wq, current);
> +	add_wait_queue(&async_new, &wq);
> +
> +	while (!kthread_should_stop()) {
> +		int tc, ec;
> +
> +		/*
> +		 * Maximum number of worker threads.
> +		 * Even on the smallest machine we want 8
> +		 * Scaling by 4 per logical CPU
> +		 * But no more than 256 to not overload stuff too much
> +		 * (and yes these are magic numbers that might need tuning)
> +		 * Calculated dynamic because early on the nr of online cpus
> +		 * is 1...
> +		 */
> +		max_threads = 4 + 4 * num_online_cpus();
> +		if (max_threads > 256)
> +			max_threads = 256;
> +
> +
> +		set_current_state(TASK_INTERRUPTIBLE);
> +
> +		tc = atomic_read(&thread_count);
> +		rmb();
> +		ec = atomic_read(&entry_count);
> +
> +		while (tc < ec && tc < max_threads) {
> +			kthread_run(async_thread, NULL, "async/%i", tc);
> +			atomic_inc(&thread_count);
> +			tc++;
> +		}
> +
> +		schedule();

Surely the thread should die again boot up? On module load
synchronisity is usually not a problem.

Personally I think it would be better to make this more generic.
Various subsystems have thread pool implementations now, and this
is just another variant that except for the sequence stuff
isn't all that much different. So it would be better to have 
a generic worker thread manager that just supports these
barriers too.

-andi

-- 
ak@...ux.intel.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/